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Foreword 



ETAPS 2001 was the fourth instance of the European Joint Conferences on 
Theory and Practice of Software. ETAPS is an annual federated conference that 
was established in 1998 by combining a number of existing and new conferences. 
This year it comprised five conferences (FOSSACS, EASE, ESOP, CC, TACAS), 
ten satellite workshops (CMCS, ETI Day, JOSES, LDTA, MMAABS, PFM, 
RelMiS, UNIGRA, WADT, WTUML), seven invited lectures, a debate, and ten 
tutorials. 

The events that comprise ETAPS address various aspects of the system deve- 
lopment process, including specification, design, implementation, analysis, and 
improvement. The languages, methodologies, and tools which support these ac- 
tivities are all well within its scope. Different blends of theory and practice are 
represented, with an inclination towards theory with a practical motivation on 
one hand and soundly-based practice on the other. Many of the issues involved 
in software design apply to systems in general, including hardware systems, and 
the emphasis on software is not intended to be exclusive. 

ETAPS is a loose confederation in which each event retains its own identity, 
with a separate program committee and independent proceedings. Its format is 
open-ended, allowing it to grow and evolve as time goes by. Contributed talks 
and system demonstrations are in synchronized parallel sessions, with invited 
lectures in plenary sessions. Two of the invited lectures are reserved for “unify- 
ing” talks on topics of interest to the whole range of ETAPS attendees. The 
aim of cramming all this activity into a single one-week meeting is to create a 
strong magnet for academic and industrial researchers working on topics within 
its scope, giving them the opportunity to learn about research in related areas, 
and thereby to foster new and existing links between work in areas that were 
formerly addressed in separate meetings. 

ETAPS 2001 was hosted by the Dipartimento di Informatica e Scienze dell’In- 
formazione (DISI) of the Universita di Genova and was organized by the following 
team: 

Egidio Astesiano (General Chair) 

Eugenio Moggi (Organization Chair) 

Maura Cerioli (Satellite Events Chair) 

Gianna Reggio (Publicity Chair) 

Davide Ancona 
Giorgio Delzanno 
Maurizio Martelli 

with the assistance of Convention Bureau Genova. Tutorials were organized by 
Bernhard Rumpe (TU Miinchen) . Overall planning for ETAPS conferences is the 
responsibility of the ETAPS Steering Committee, whose current membership is: 




VI 



Foreword 



Egidio Astesiano (Genova), Ed Brinksma (Enschede), Pierpaolo Degano 
(Pisa), Hartmut Ehrig (Berlin), Jose Fiadeiro (Lisbon), Marie-Claude 
Gaudel (Paris), Susanne Graf (Grenoble), Furio Honsell (Udine), Nigel 
Horspool (Victoria), Heinrich HuBmann (Dresden), Paul Klint (Amster- 
dam), Daniel Le Metayer (Rennes), Tom Maibaum (London), Tiziana 
Margaria (Dortmund), Ugo Montanari (Pisa), Mogens Nielsen (Aarhus), 
Hanne Riis Nielson (Aarhus), Fernando Orejas (Barcelona), Andreas 
Podelski (Saarbriicken), David Sands (Goteborg), Don Sannella (Edin- 
burgh), Perdita Stevens (Edinburgh), Jerzy Tiuryn (Warsaw), David 
Watt (Glasgow), Herbert Weber (Berlin), Reinlrard Wilhelm (Saar- 
briicken) 

ETAPS 2001 was organized in cooperation with 
the Association for Computing Machinery 

the European Association for Programming Languages and Systems 
the European Association of Software Science and Technology 
the European Association for Theoretical Computer Science 

and received generous sponsorship from: 

ELSAG 

Fondazione Cassa di Risparmio di Genova e Imperia 

INDAM - Gruppo Nazionale per l’Informatica Matematica (GNIM) 

Marconi 

Microsoft Research 
Telecom Italia 
TXT e-solutions 
Universita di Genova 

I would like to express my sincere gratitude to all of these people and organiza- 
tions, the program committee chairs and PC members of the ETAPS conferen- 
ces, the organizers of the satellite events, the speakers themselves, and finally 
Springer- Verlag for agreeing to publish the ETAPS proceedings. 
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Donald Sannella 
ETAPS Steering Committee chairman 




Preface 



This volume contains the 28 papers presented at ESOP 2001, the Tenth Euro- 
pean Symposium on Programming, which took place in Genova, Italy, April 4-6, 
2001. The ESOP series began in 1986, and addresses both practical and theore- 
tical issues in the design, specification, and analysis of programming languages 
and systems. 

The call for ESOP 2001 encouraged papers addressing (but not limited to) 

— Programming paradigms (including functional, logic, concurrent, and object- 
oriented) and their integration; 

— Semantics with applications to the development of correct, secure, and effi- 
cient software and systems; 

— Advanced type systems, program analysis, program transformation. 

The volume begins with two invited contributions. The first contribution belongs 
to ETAPS as a whole, and accompanies the “unifying” ETAPS invited talk given 
by Luca Cardelli. The second contribution is from the ESOP invited speaker, 
John Mitchell. The remaining 26 papers were selected by the program committee 
from the 76 submissions, and include one short paper which accompanied a tool- 
demo presentation. 

Each submission was reviewed by at least three referees, and papers were sel- 
ected in the latter stages of a two week discussion phase. My thanks to the mem- 
bers of the program committee and other referees for their hard work. Thanks 
also to Christian Probst for help with the conference management software, and 
to Don Sannella for steering the ETAPS ship so smoothly. 
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A Query Language Based on the Ambient Logic 



Luca Cardelli 1 and Giorgio Ghelli 2 

1 Microsoft Research, 1 Guildhall Street, Cambridge, UK 
2 Universita di Pisa, Dipartimento di Informatica, Corso Italia 40, Pisa, Italy 



Abstract. The ambient logic is a modal logic proposed to describe the 
structural and computational properties of distributed and mobile com- 
putation. The structural part of the ambient logic is, essentially, a logic 
of labeled trees, hence it turns out to be a good foundation for query 
languages for semistructured data, much in the same way as first order 
logic is a fitting foundation for relational query languages. We define here 
a query language for semistructured data that is based on the ambient 
logic, and we outline an execution model for this language. The language 
turns out to be quite expressive. Its strong foundations and the equiva- 
lences that hold in the ambient logic are helpful in the definition of the 
language semantics and execution model. 



1 Introduction 

This work arises from the unexpected convergence of studies in two different 
fields: mobile computation and semistructured data. 

Unstructured collections, or unstructured data, are collections that do not 
respect a predefined schema, and hence need to carry a description of their own 
structure. These are called semistructured when one can recognize in them some 
degree of homogeneity. This partial regularity makes semistructured collections 
amenable to be accessed through query languages, but not through query lan- 
guages that have been designed to access fully structured databases. New lan- 
guages are needed that are able to tolerate the data irregularity, and that can 
be used to query, at the same time, both data and structure. Semistructured 
collections are usually modeled in terms of labeled graphs, or labeled trees 0- 

The ambient logic is a modal logic proposed to describe the structural and 
computational properties of distributed and mobile computation m- The logic 
comes equipped with a rich collection of logical implications and equivalences. 
The structural part of the ambient logic is, essentially, a logic designed to describe 
properties of labeled trees. It is therefore a good foundation for query languages 
for semistructured data, much in the same way as first order logic is a fitting 
foundation for relational query languages. First order logic is a logic of predicates 
(i.e. relations) and therefore it is particularly suitable to describe relational data. 
But, to describe tree-shaped data, we need a more suitable logic: a logic of trees 
or graphs. 
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Here we define a query language for semistructured data that is based on the 
ambient logic, and we outline an execution model for this language. The language 
turns out to be quite expressive. Its strong foundations and the equivalences that 
hold in the ambient logic are helpful in the definition of the language semantics 
and execution model. 

The paper is structured as follows. In this section we present a preview of the 
query language, and compare it with related proposals. In Section 0 we define 
the tree data model. In Section 0 we present the logic, upon which the query 
language, defined in Section 0 is defined. In Section Owe present the evaluation 
model. In Section 0 we draw some conclusions. 



1.1 A Preview 

Consider the following bibliography, expressed in the syntax of our language 
TQL, which we explain in detail later. Informally, a\F\ represents a piece of data 
labeled a with contents F. The contents can be a collection of similar pieces of 
data, separated by “|”. When the collection is empty, we can omit the brackets, 
so that, for example, POPL[ ] can be written as POPL. 

The bibliography below consists of a set of references all labeled article. Each 
entry contains a number of author fields, a title field, and possibly other fields. 

ARTICLES = 

article[ author[Cardelli\ | author[Gordon] | title[Anytime-Anywhere\ 

| conference[POPL\ \ year[2000] 

| keyword[Ambient-Calculus } \ keyword[Logic ] ] 

article[ author[Cardelli\ | title[Wide-Area-Computation] 

| booktitle[ICALP] | year[1999] \ pages[403~444\ \ publisher[SV\ ] \ 

article[ author[Ghelli] | author[Pierce ] \ title[Bounded-Existentials } 

| journal[TGS\ \ year[1998 \ } 

Suppose we want to find all the papers in ARTICLES where one author is 
Cardelli', then we can write the following query: 

from ARTICLES t= .article[ X] 

X 1= ,author[ Cardelli] 

select paper[X\ 

The query consists of a list of matching expressions contained between from 
and select, and a reconstruction expression, following select. The matching ex- 
pressions bind X with every piece of data that is reachable from the root 
ARTICLES through an article path, and such that a path author goes from 
X to Cardelli', the answer is paper [author [Cardelli] | author [Gordon] \ . . .] \ 
paper [author[Cardelli\ | title[Wide Area Computation \ \ ...], i.e. the first two 
articles in the databases, with the outer article rewritten as paper. 

This query language is characterized by the fact that a matching expression 
is actually a logic expression combining matching and logical operators. For 
example, the following query combines path expressions and logical implication 
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(=£■) to retrieve papers with no other author then Cardelli. Informally, T matches 
anything, hence the second condition says: if X is an author, then it is Cardelli. 

from ARTICLES t= .article[X\ 

X t= ,author[ T] => . author[Cardelli } 
select X 

Moreover, queries can be nested, giving us the power to restructure the collection, 
as we explain later. 

1.2 Comparisons with Related Proposals 

In this paper we describe a logic, a query language, and an abstract evaluation 
mechanism. 

The tree logic can be compared with standard first order formalizations of 
labelled trees. Using the terminology of |3j, we can encode a labeled tree with a 
relation Ref(source:OID, label:A, destination: O ID). The nodes of the tree are the 
OIDs (Object IDentifiers) that appear in the source and destination columns, 
and any tuple in the relation represents an edge, with label label. Of course, 
such a relation can represent a graph as well as a tree. It represents a forest if 
destination is a key for the relation, and if there exists an order relation on the 
OIDs such that, in any tuple, the source strictly precedes the destination. 

First order formulas defined over this relation already constitute a logical 
language to describe tree properties. Trees are represented here by the OID of 
their root. We can say that, for example, “the tree x is a[]” by saying: 

By. Ref (x, a, y) A f/y',y". ~^Ref(y,y' 1 y")) A (fix' ,x" . x" / y => ~^Ref(x,x',x")) 

There are some differences with our approach. First, our logic is ‘modal’, which 
means that a formula A is always about one specific ‘subject’, that is the part of 
the database currently being matched against A. First order logic, instead, does 
not have an implicit subject: one can, and must, name a subject. For example, 
our modal formula a[] implicitly describes the ‘current tree’, while its translation 
into first order logic, given above, gives a name x to the tree it describes. 

Being ‘modal’ is neither a merit nor a fault, in itself; it is merely a difference. 
Modality makes it easier to decribe just one tree and its structure, whereas it 
makes it more difficult to describe a relationship between two different trees. 

Apart from modality, another feature of the ambient logic is that its funda- 
mental operators deal with one-step paths (a[_4]) and with the composition of 
trees {A \ A '), whereas the first order approach describes everything in terms of 
one-step paths (f?e/(ol, a, o2)). Composition is a powerful operator, at least for 
the following purposes: 

— it makes it easy to describe record-like structures both partially (&[] | c[] | T 
means: contains b[], c[], and possibly more fields) and completely (&[] | c[] 
means: contains 6[], c[] and only &[], c[]); complete descriptions are difficult in 
the path based approach; 

— it makes it possible to bind a variable to ‘the rest of the record’, as in ‘X is 
everything but the title’: paper[title[ T] | X], 
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The query language we described derives its essential from-select structure 
from set-theoretics comprehension, in the SQL tradition, and this makes it sim- 
ilar to other query languages for semistructured data, such as StruQL \mm . 
Lorel f511 Sj . XML-QL pS], Quilt [13], and, to some extent, YATL [32]. An in- 
depth comparison between the XML-QL, YATL, and Lorel languages is carried 
out in m, based on the analysis of thirteen typical queries. In DU we wrote 
down those same queries in TQL; the result of this comparison is that, for the 
thirteen queries in ixa. their TQL expression is very similar to the correspond- 
ing XML-QL, with a couple of exceptions. First, those XML-QL queries that, 
in El, are expressed using Skolem functions, have to be expressed in a different 
way in TQL, since we do not have Skolem functions in the current version of 
TQL. However, our Skolem-free version of these queries is not complex. Second, 
XML-QL does not seem to have a general way of expressing universal quantifi- 
cation, and this problem shows up in the query that asks for pairs of books with 
the same set of authors; this is rather complex to express in XML-QL, but it is 
not difficult in TQL. Another related class of queries that are simpler to express 
using TQL are those related to the non-existence of paths, such as ‘find all the 
papers with no title’ or ‘find all the papers whose only author, if any, is Ghelli’. 
Lorel does not have these problems, since it allows universal quantification. Quilt 
and XDuce PI are Turing complete, hence are more expressive than the other 
languages we cited here. 

One important feature of TQL is that it has a clean semantic interpretation, 
which pays off in several ways. First, the semantics should make it easier to 
prove the correctness and completeness of a specific implementation. Moreover, 
it simplifies the task of proving equivalences between different logic formulas or 
queries. To our knowledge, no such formal semantics has been defined for YATL. 
The semantics of Lorel has been defined, but looks quite involved, because of 
their extensive use of coercions. 



2 Information Trees 

We represent semistructured data as information trees. In this section we first 
define information trees, then we give a syntax to denote them, and finally we 
define an equivalence relation that determines when two different expressions 
denote the same information tree. 

2.1 Information Trees 

We represent labeled trees as nested multisets; this corresponds, of course, to 
unordered trees. Ordered trees (e.g. XML data) could be represented as nested 
lists. This option would have an impact on the logic, where the symmetric A \ B 
operator could be replaced by an asymmetric one, A\ B. This change might 
actually simplfy some aspects of the logic, but in this paper we stick to the 
original notion of unordered trees from sna, which also matches some recent 
directions in XML |T]. 

For a given set of labels A, we define the set XT of information trees, ranged 
over by /, as the smallest collection such that: 
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— the empty multiset, {}, is in XT', 

— if to is in A and I is in XT then the singleton multiset {(to,/)} is in XT', 

— XT is closed under multiset union (+J gJ -A/(j), where J is an index set, and 
Me J-> XT. 

2.2 Information Terms 

We denote finite information trees by the following syntax of information term 
(info-terms), borrowed from the ambient calculus 0. We define a function [F] 
mapping the info-term F to the denoted information tree. To this aim, we define 
three operators, 0, to[_] and |, on the domain of the information trees, which we 
use to interpret the corresponding operations on info-terms. 

Info-terms and their information tree meaning 

i 1 

F ::= info-term 

0 denoting the empty multiset 
m[F) denoting the multiset {(to, F)} 

F | F denoting multiset union 



[ 0 ] 


~ def 


0 


— def 


{} 


[mm 


— def 


TO [IF]] 


~ def 


{( m JF])} 


IF' | F"j 


~ def 


IF'] | [F"] 


— def 


IF'] W IF"] 



We use II to denote the set of all terms generated by this grammar, also 
using parentheses for precedence. We often abbreviate to[ 0] as to[], or as m. We 
assume that A includes the disjoint union of each basic data type of interest 
(integers, strings. . . ), hence 5[0], or 5, is a legitimate info-term. We assume that 
“|” associates to the right, i.e. F \ F' \ F" is read F \ (F' \ F"). 



2.3 Congruence over Info-Terms 

The interpretation of info-terms as information trees induces an equivalence 
relation F = F' on info-terms. This relation is called info-term congruence , and 
it can be axiomatized as follows. 

Congruence over info-terms 

5TF 1 

F' = F => F = F' 

F = F', F' = F" => F = F" 

F = F' => m[F] = m[F'} 

F = F'^F\F"=F'\ F" 

F | 0 = F 

F | F' = F' | F 

(F | F') \ F" = F\ {F' | F") 

i i 
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This axiomatization of congruence is sound and complete with respect to the 
information tree semantics. That is, F = F' if and only if F and F' represent 
the same information tree. 



2.4 Information Trees, OEM Trees, UnQL Trees 

We can compare our information trees with two popular models for semistruc- 
tured data: OEM data E3J and UnQL trees 0. The first obvious difference is 
that OEM and UnQL models can be used to represent both trees and graphs, 
while here we focus only on trees. We are currently working on extending our 
model to include labeled graphs as well, but we prefer to focus on the simpler 
issue of trees, which is rich enough to warrant a separate study. 

UnQL trees are characterized by the fact that they are considered modulo 
bisimulation, which essentially means that information trees are seen as sets 
instead of multisets. For example, m[n\\ | n[]] is considered the same as m[n[|]; 
hence UnQL trees are more abstract, in the precise sense that they identify more 
terms than we do. 

On the other hand, information trees are more abstract than OEM data, 
since OEM data can distinguish a DAG from its tree-unfolding. 



3 The Tree Logic 

In this section we present the tree logic. The tree logic is based on Cardelli and 
Gordon’s modal ambient logic, defined with the aim of specifying spatial and 
temporal properties of the mobile processes that can be described through the 
ambient calculus m- The ambient logic is particularly attractive because it is 
equipped with a large set of logical laws for tree-like structures, in particular 
logical equivalences, that can provide a foundation for query rewriting rules and 
query optimization. 

We start here from a subset of the ambient logic as presented in but we 
enrich it with information tree variables, label comparison, and recursion. 

3.1 Formulas 

The syntax of the tree logic formulas is presented in the following table. 

The symbol ~, in the label comparison clause, stands for any label compar- 
ison operator chosen in a predefined family 0; we will assume that 0 at least 
contains equality, the SQL string matching operator like, and their negations. 
The positivity condition on the recursion variable £ means that an even number 
of negations must be traversed in the path that goes from each occurrence of £ 
to its binder. 

Formulas: 

i 1 

?y::= label expression 

n label constant 

x label variable 
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A,B ::= 

0 

rj[A] 

A | B 

T 

^A 

AaB 

X 

3x.A 
3X .A 
V ~ rf 

uCA 



formula 

empty tree 
location 
composition 
true 

negation 
conjunction 
tree variable 

quantification over label variables 
quantification over tree variables 
label comparison 
recursion variable 

recursive formula (least fixpoint); £ may appear only positively 



The interpretation of a formula A is given by a semantic map [_4.] Pi s that maps 
A to a set of information trees, with respect to the valuations p and <5. The 
valuation p maps label variables x to labels (elements of A) and tree variables 
X to information trees, while <5 maps recursion variables £ to sets of information 
trees. 



Formulas as sets of information trees 



[0 ] P ,s 


— def 


{0} 




W[A}j P ,s 


— def 


{p{v)[i] 1 f e M P ,4 




{A | B\p,s 


~def 


{i\r | ielA\ p , s ,r 


e I B\ PiS } 


[T] P ,« 


~ def 


IT 






— def 


IT\lA] p ,s 




[A A B\ P) s 


~def 


M]p,*n [ B} p ,s 




Wm 


— def 


M*)} 




|3x.yl] p! 5 


— def 


UrtgA 5 




{3X.A\ Pt 5 


~def 


U/exr ["^lp[Arn./],(5 




IV ~ V Ip, <5 


~def 


if p{p) ~ p(i f) then IT else 0 


lv£-A]p,s 


— def 


n {s c it i ^ 2 mi 


p,5K^S]} 


[£lp,« 


— def 





i i 



This style of semantics makes it easier to define the semantics of recursive 
formulas. Some consequences of the semantic definition are detailed shortly. 

[ 0] Pi ,5 is the singleton {0}. [[ 77 [-4 .]] 5 contains the information tree m[J], if 
to = p{rj) and / is in [_ 4 ] p> , 5 . (We assume that p maps any label in A to itself, 
so that we can apply p to rj even when 77 is not a variable.) For each I in [- 4] p> ,5 
and I' in [£>] p ,, 5 , [-4 | H] p , 5 contains the information tree / | I'. [T] p ^ is the set 
of all information trees (while its negation F denotes the empty set). |^^l ] p ,5 is 
the complement of [_A] P . 5 with respect to the set of all information trees IT . I 
is in [_ 4 a £>] Pj< 5 if it is in [_4] Pj 5 and in p?] Pj < 5 . I is in [3a’..4] p , s if there exists 
some value n for x such that / is in I^l] p [a; 1 _>.n], s- Here p[x 1 — > n] denotes the 
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subtitution that maps x to n and otherwise coincides with p. | r] ~ rf\ p> $ is the 
set XT if the comparison holds, else it is the empty set. [p^.Alp, a is the least 
fixpoint (with respect to set inclusion) of the monotonic function that maps any 
set of information trees S to [„4] Pi 

The meaning of a variable X is given by the valuation p. Valuations connect 
our logic to pattern matching; for example, [m[n[0]]] is in [x[Af]] P) 5 if p maps x 
to m and X to [n[0]]. The process of finding all possible p’s such that I £ [_4.]p, g 
is our logic-based way of finding all possible answers to a query with respect to 
a database I. 

We say that F satisfies A under p, 8, when the information tree [F] is in the 
set |./4 ] p , 5, and then we write F I = Pt g A: 

F l= p ,5 A =def [F] S 

Satisfaction enjoys the following properties, which are easily derived and help 
making the above semantic definition more explicit. These properties may form 
the basis of a matching algorithm of F against A. 

Some properties of satisfaction 

1 1 



F 


^p,<5 


0 


<G> 


F = 0 


F 


^p,<5 


V[A] 


<G> 


3F' . F = p{ri)[F'] A F'N p , { d 


F 


^P,<5 


A | B 


<G> 


3F', F" . F = F'\F" A F' l=p )4 A A F" \= p>s B 


F 


^p,<5 


T 






F 


^p,<5 


-A 


<G> 


“■( F Np )4 A) 


F 


^p,< 5 


AAB 


<G> 


F Np )4 A A F l=p i5 B 


F 


^P,<5 


3 xA 


<G> 


3ffl£ A. F ^ p^x^m] ,<5 A 


F 


^P,<5 


3 X A 


<G> 


3 IgXT- F ^ p [x>^i},s -4 


F 


^P,<5 


V ~ v' 


<G> 


p(v) ~ pW) 


F 


^P,<5 


pfA 


<G> 


F \= p .g >4{£ pfA} 


F 


^P,<5 


X 


<G> 


m = PW 


F 


^P,<5 




<G> 


m e S(0 



3.2 Some Derived Formulas 

As usual, negation allows us to define many useful derived operators, as described 
in the following table. 



Derived formulas: 



vh> -4] 


~def 


?h-4]) 


A\\B 


~def -*{-^A ~>B) 


F 


— def 




Ay B 


= def ~<{^A A ~<B) 


\/xA 

vfA 

1 


— def 

— def 


->(p^.->A.{(, <- ->£}) 


\/XA 


— def ->{3X.->A) 

1 



F \= m[=> A] means that ‘it is not true that, for some F', F = m[F'] and not 
F' \= A\ i.e. ‘if F has the shape m[F'], then F' h A’. To appreciate the difference 
between m[A] and its dual m[=> A], consider the following statements. 
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— F is an article where Ghelli is an author: F \= article[author[Ghelli] |T] 

— If F is an article, then Ghelli is an author: F \= article[=> author[Ghelli] |T] 

F \= A || B means that ‘it is not true that, for some F' and F", F = F' \ F" 
and F' 1= -i A and F" t= ~>B’, which means: for every decomposition of F into 
F' | F", either F' 1= A or F" 1= B. To appreciate the difference between the | 
and the 1 1 operators, consider the following statements. 

— There exists a composition of F into F' and F ", such that F' satisfies 
article [A] , and F" satsfies T; i.e. , there is an article inside F that satis- 
fies A: F 1= article{A\ | T 

— For every decomposition of F into F' and F", either F' satisfies article[=> A], 
or F" satisfies F; i.e., every article inside F satisfies A: F 1= article[=> A] || F 

The dual of the least fixpoint operator fj£.A is the greatest fixpoint opera- 
tor v^.A. For example is equivalent to F, while is equivalent to T. 
More interestingly, /i£.0 V m[£] describes every information tree that matches 
m[m[. . . m[]]], and, on finite trees, it is equivalent to V m[£]. However, 
if we consider infinite trees, the distinction between least and greatest fix- 
point becomes more important. For example, the infinite tree m[m[. . .]] satisfies 
^.0Vm[(], but does not satisfy //£.0 Vm[£]. When we consider only finite trees, 
as we do here, the p and v operators are quite similar in practice, since most 
interesting formulas have a single fixpoint. 

Satisfaction over the derived operators enjoys the following properties, most 
of which are easily derived from the definition, while others are more subtle. 
For example, the properties of greatest fixpoints include a coinduction principle. 
Again, these properties may form the basis for a matching algorithm. 

Some properties of satisfaction for derived formulas 

'-'F l = p><5 F 

F h p , 4 n[=* A] & VF'. (F = p{ri)[F'] =► F' b p>d - A) 

F h P|4 A || B VF', F" . F = F'\F" => (F' l= P|5 A V F" h P)4 B ) 

F N Pi< 5 Ay B <G> F t= Pi 5 A V F h Pi< 5 B 
F l= Pi 5 Mx.A VmG A F N p [ Xh ^. m ] i5 A 
F h p , 4 VT.A ^ V/gIT. F \= p[x »r\,s A 
F N p ,<s v£-A <G> F t= Pi 5 A{£ g- v^.A} 

F t = pp 5 v£.A 3 B. F \= P)S B A VF'. F' l= Pj4 B =» F' l= p>4 A{£ <- B} 

i i 

Many logical equivalences have been derived for the ambient logic, and are in- 
herited by the tree logic. We list some of them here. These equivalences could 
be exploited by a query logical optimizer. 



Some equations 

i 

rj[A] <G> 17 [T] A 77[=> A] 

17 [F] F 

rj[A A A 1 ] <G> rj[A] A r][A'] 

rj[A V A!] <G> rj[A] V rj[A' ] 



?7[=> A] <G> 77 [T] => r][A } 

77 [=>- T] •£=> T 

r?[=> A\/ A'] <G> rj[=> A] V ??[=> A 1 ] 

r?[=> A A A ] <G> rj[=> A ] A rj[=> A'] 
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17 [3a;. .4] <G> 3 x.r][A] ( x ^ 77 ) 

? 7 [Va;.A] <G> Va;. 77 [ 4 ] (x ^ 77 ) 

77 [ 3 A’. 4 ] -o- 3^.77 [ 4 ] 

77^4.4] <G> VAf.77[4] 



A| 


A' 


A! | A 


(4 


| A') | A" 


A | (4' | 4") 


4 | 


F 


<G> F 


T I 


T 


<G> T 


4 | 


(4'V4")« (4 | A') V (4 | 4") 


4 | 


3a:. 4' 


3a’. 4 1 A! (x£FV(A)) 


4 | 


Vx.4' 


& Vx.A | A' (x^FV(A)) 



L 



?7[=> Vz.4] 


<G> Mx.y[=> 4] (x ^ rj) 


77[=> 3a;. 4] 


<G> 3a;.?7[=> 4] ( x ^ rj) 


7?[=> MX. A] 


VA.?7[=> A] 


r] [=> 3 X. A] 


<G> 3X.rj[=> 4] 


A || A' 


A' 1 1 A 


(4 || A') || 4" 


’•»4 || [A' || 4") 


A||T 


<G> T 


F II F 


<G> F 


4 || (4' A 4")^ (4 || 4') A (4 || 4") 


4 || Vx.4' 


<G> Vx.4 || A! (xiFV(A)) 


A || 3a;. 4' 


& 3x.A || 4' {x£FV(A)) 



J 



3.3 Path Formulas 

All query languages for semistructured data provide some way of retrieving all 
data that is reachable through a path described by a regular expression. The tree 
logic is powerful enough to express this kind of queries. We show this fact here 
by defining a syntax for path expressions, and showing how these expressions 
can be translated into the logic. This way, we obtain also a more compact and 
readable way of expressing common queries, like those outlined in the previous 
section. 

Consider the following statement: X is some article found in the ARTICLES 
collection, and some author of X is Cardelli. We can express it in the logic using 
the 7n [4] | T pattern as: 

ARTICLES 1= article[X A ( author [Cardelli] | T)] | T 

Using the special syntax of path expressions, we express the same condition as 
follows. 

ARTICLES 1= . article (X).author[Cardelli] 

Our path expressions support also the following features: 

— Universally quantified paths: X is an article and every author of X is 
Cardelli. 

ARTICLES \= . article (X)\ author [Cardelli] 

— Label negation: X is an article where Ghelli is the value of a field, but is not 
the author. 

ARTICLES \= . article(X).(->author)[Ghelli ] 

— Path disjunction: X is an article that either deals with SSD or cites some 
paper y that only deals with SSD. 

ARTICLES b . article (X) (.keyword V . cites. article{y)\keyw or d)[SSD] 

— Path iteration (Kleene star): X is an article that either deals with SSD, or 
from which you can reach, through a chain of citations, an article that deals 
with SSD. 

ARTICLES b . article{X) (.cites. article)* .key w or d[SSD] 
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— Label matching: there exists a path through which you can reach some held 
X whose label contains e and mail (% matches any substring). 

ARTICLES N {.%)* {.%e%mail%)[X] 

We now define the syntax of paths and its interpretation. 



Path formulas: 



1 

a ::= 


i 

label matching expression 


V 


matches any n such that n like 


-*a 


matches whatever a does not match 


/?::= 


path element 


.a 


some edge matches a 


\a 


each edge matches a 


p,q ■■= 


path 


(3 


elementary path 


pq 


path concatenation 


* 

P 


Kleene star 


PV q 


disjunction 


P(X) 

1 


naming the tree at the end of the path 

i 



A path-based formula p[A\ can be translated into the tree logic as shown below. 
We first define the tree formula Matches(x, a) as follows: 

Matches(x,rj) =def x like 
Matches(x,^a) =def ~<Matches(x,a) 

Path elements are interpreted by a translation, [_] p , into the logic, using the 
patterns rri[A] | T and to[=> ^4] 1 1 F that we have previously presented: 

[.a[4]] p =def (3 x.Matches(x, a) A a:[[4] p ]) | T 
[!a[4]] p =def (' Vx.Matches(x, a ) a;[=^ |-4] p ]) || F 

General paths are interpreted as follows. p*[-4] is recursively interpreted as ‘either 
A holds here, or p*[A] holds after traversing p\ Target naming p(X)[A] means: 
at the end of p you find X , and X satisfies A\ hence it is interpreted using 
logical conjunction. Formally, path interpretation is defined as shown below; path 
interpretation translates all non-path operators as themselves, as exemplified for 
T and |. 



lpq[A]] p = 
I (pv<i)[A]} p = 
[T] p 



def b[«[^]]F b*[-4]F 

def b[4]] p V lq[A}r lp(X)[A\r 
T [ A | A'j p 



= def (4. A v [p[£]] p 

= def \p[X A 4]] P 
=def lAj p I [4'F 



— def 
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3.4 Tree Logic and Schemas 

Path formulas explore the vertical structure of trees. Our logic can also express 
easily horizontal structure, as is common in schemas for semistructured data. 
(E.g. in XML DTDs, XDuce [E3j and XMLSchema 0Q. However, the present 
version of our logic deals directly only with unordered structures.) 

For example, we can extract the following regular-expression-like sublan- 
guage, inspired by XDuce types. Every expression of this language denotes a 
set of information trees: 



0 

A | B 
A\/ B 
n[A\ 

A* = def 0 V (A U) 
A+ =def A I A* 
A?= def OVA 



the empty tree 

an A next to a B 

either an A or a B 

an edge n leading to an A 

a finite multiset of zero or more M’s 

a finite multiset of one or more M’s 

optionally an M 



In general, we believe that a number of proposals for describing the shape of 
semistructured data can be embedded in our logic. Each such proposal usually 
comes with an efficient algorithm for checking membership or other properties. 
These efficient algorithms, of course, do not fall out automatically from a general 
framework. Still, a general frameworks such as our logic can be used to compare 
different proposals. 



4 The Tree Query Language 

In this section we build a full query language on top of the logic we have defined. 

4.1 The Query Language 

A query language should feature the following functionalities: 

— binding and selection: a mechanism to select values from the database and 
to bind them to variables; 

— construction of the result: a mechanism to build a result starting from the 
bindings collected during the previous stage. 

Our Tree Query Language (TQL) uses the tree logic for binding and selection, 
and tree building operations to construct the result. Logical formulas M are as 
previously defined. 

TQL queries: 

i 1 

Q ::= query 

from Q t= M select Q' valuation-collecting query 

X matching variable 

0 empty result 
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Q | Q composition of results 

r)[Q\ nesting of result 

f(Q) tree function, for any / in a fixed set 

i i 

We allow some tree functions /, chosen from a set ^ of functions of type 
IT — > IT, to appear in the query. For example: 

— count (I), which yields a tree n[0], where n is the cardinality of the multiset 

/; 

— op(I), where op is a commutative, associative integer function with a neutral 
element; if all the pairs in I have a shape n[I'], where n is a natural number, 
then op (I) combines all the n’s using the op operation obtaining the integer 
r, and returns r[0]. 

In practice, these functions would include user-defined functions written in an 
external programming language. 



4.2 Query Semantics 

The semantics of a query is defined in the following table. The interesting case 
is the one for from Q t= A select Q' . In this case, the subquery Q' is evaluated 
once for each valuation p' that extends the input valuation p and such that 
\Q\ P £ |-4J f) pp. all the resulting trees are then combined using the | operator. 
The notation p ,v D p v means that V' D V and that p ,v and p v coincide 
over V. For F £ R v — > IT , we define Par p v &R v F(p v ) = de f (+) p v gi jv F(p v ), 
where ttl is multiset union, namely the information tree operator that is used to 
interpret |. 



Query semantics 

[rjpv = p v (t) 1 

[o] P v = o 

IQ I Q'l P v = [<9]pv | [Q']pv 

[m[Q]]pV = m[[Q]p V ] 

I*[Q]]pV = p v (x)[[Q] p v] 

[/(<3)]p v = /(IQlpv) 

[ from Q t= A select Q'] p v 

= Par p ,w ’ e { p ' v ' | v'=vufkM), p ' v 'd p v , IQ] p ve[A] p , v / e } IQlp'v' 

i 1 i 



According to this semantics, the result of a query from Q' t= A select Q" can 
be an infinite multiset. Therefore, in a nested query, the database Q' can be 
infinite, even if we start from a finite initial database. Obviously, one would not 
like this to happen in practice. One possible solution is to syntactically restrict 
Q’ to a variable X . Another solution is to have a static or dynamic check on the 
finiteness of the result; one such option is dicussed in Section 14.41 
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4.3 Examples of Queries 

We explain the query operators through examples. As in Section 11.11 we abbre- 
viate a query 

from Q \= A select from Q' t= A! select Q" 
as 

from Q t= A, Q' t= A! select Q" . 

The database ARTICLES is the one given in Section II . 1 1 

All papers whose only author (if any) is Cardelli can be retrieved by the 
following query (where we use X A . . . as an alternative to a nested binder 
X\=...): 

from ARTICLES 1= .article[X A lauthor[Cardelli]\ select X 

We may use disjunction to find both e-mails and emails inside some author 
field. 

from ARTICLES t= .article[. author [,e-mail[X] V .emozZ[A’]]] 
select e-mail[X] 

Using recursion, we look for e-mail at the current level or, recursively, at any 
inner nesting level Jj 

from ARTICLES 1= p,f. .e-mail[X] V . email[X ] V 3x. .a;[£] 
select e-mail[X ] 

The following query binds two label variables y and z to the label and the 
content of a field y[z], where z is dike %Ghelli% ’ ( like matches to any 
substring). Recursion may be used to look for such fields at any depth. 

from ARTICLES 1= . article[.y[z\ A z like %Ghelli%\ 
select found[label[y\ \ content[z\\ 

Query nesting allows us to restructure data. For example, the following query 
rearranges papers according to their year of publication: for each year X (outer 
from), it collects all the papers of that year. The composition Year[X] \ Z binds 
Z to all fields but the year; this way of collecting all the siblings except one is 
impossible, or difficult, in most other query languages. 

from ARTICLES h .article[.Year[X]\ 
select publications J>y jy ear [ Year[X } 

| ( from ARTICLES \= . article[Year[X ] \ Z] 
select article[Z ) ) 

] 

Relational-style join queries can be easily written in TQL either by matching 
the two data sources with two logical expressions that share some variables (equi- 
joins) or by exploiting the comparison operators. Universal quantification can be 
expressed both on label and tree variables; more examples can be found in m- 

1 When every X is inside an m[] operator, like in this example, recursion is guaranteed 
to terminate, but we still have enough flexibility to express complex queries, such as 
queries that evaluate boolean circuits m- 
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4.4 Safe Queries 

It is well-known that disjunction, negation, and universal quantification create 
‘safety’ problems in logic-based query languages. The same problems appear in 
our query language. 

Consider for example the following query: 

from db\= [author[X] V autore[y]) | T select author[X ] | autore[y] 

Intuitively, every entry in db that is an author binds X but not y , and vice- 
versa for autore entries. Formally, both situations generate an infinite amount 
of valuations; for example, if p(db) = author[m[ ]], then {p' | [d6] p e [*4]p', e } is 
the infinite set 

{(db>— > author[m[}}, X\ — >m[], jV 1- >1) | I G IT} . 

Negation creates a similar problem. Consider the following query. 

from db t= -i author [X] select notauthor[X ] 

Its binder, with respect to the above input valuation, generates the following 
infinite set of bindings: 

{(db<-> author[m\}\, X<->I) | I G IT, I ^ m[]}} , 
and the query has the following infinite result: 

{notauthor [/] | lGlT,I^m\\}. 

These queries present two different, but related, problems: 

— their semantics depends on the sets A and IT of all possible labels and 
information trees; 

— their semantics is infinite. 

We say that a query is safe when its semantics is finite. Query safety is 
known to be undecidable for the relational tuple calculus 0, and we suspect 
it is undecidable for our calculus too. However, as in relational calculi, it is not 
difficult to devise some sufficient syntactical conditions for safety, and to solve the 
non-safety problem by restricting the language to the syntactically safe queries. 
A different way to solve the problem is to allow unsafe queries, and to design 
a query processor for them. Our semantics accounts for unsafe queries, since it 
does not restrict the set of valuations generated by a binder to be finite, nor 
does it restrict the query answer to be finite. 

5 Query Evaluation 

In this section we define a query evaluation procedure. This procedure is really 
a refined semantics of queries, which is intermediate in abstraction between the 
semantics of Section 14. ’41 and an implementation algorithm. It is based on an 
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algebra of trees and tables that is suggestive of realistic implementations, and 
may be seen as a specification of such implementations. In Pisa we have realized 
one such implementation, which is described in E3HI- 

The query evaluation procedure is based on the manipulation of sets of val- 
uations. These sets, unfortunately, may be infinite. For a real implementation, 
one must typically find a finite representation of infinite sets. Moreover, at the 
level of query manipulations, one would like to push negation to the leaves, in- 
troducing dualized logical operators as indicated in the first table in Section ET2I 
These dualized operators also become part of an implementation. We do not deal 
here with the possible ways of finitely representing these infinite sets, or how to 
implement operators over them. In E3EI, though, we describe a technique for 
finitely representing sets of valuations in terms of a finite disjunction of a set of 
conjunctive constraints over the valuations, in the style of jams. 

Any practical implementation of a query language is based on the use of 
particular efficiently implementable operators, such as relational join and union. 
We write our query evaluation procedure in this style as much as possible, but 
we naively use set complement to interpret negation, and we do not deal with 
dualized operators. 

Our query evaluation procedure shows how to directly evaluate a query to a 
resulting set of trees. In database technology, instead, it is typical to translate 
the query into an expression over algebraic operators (which, in 1211181 and in 
XML Query Algebra (2J, include also operators such as if-then-else, iteration 
and fixpoint). These expressions are first syntactically manipulated to enhance 
their performance, and finally evaluated. We ignore here issues of translation 
and manipulation of intermediate representations. 

The core of the query evaluation problem is binder evaluation. A binder 
evaluation procedure takes an information tree I and a formula A, that is used 
as a pattern for matching against I. The procedure takes also a valuation p and 
returns the set of all the valuations for the free variables of A that are not in 
the domain of p. 

To describe the procedure, we first introduce an algebra over tables. Tables 
are sets of valuations (here called rows) . We then use this algebra to define the 
evaluation procedure. 



5.1 The Table Algebra 

Let V = V\,...,V n be a finite set of variables, where each variable Vi is either an 
information tree variable A, whose universe U(X) is defined to be the set IT 
of all information trees, or a label variable x, whose universe U{x) is defined to 
be the set A of all labels. 

A row with schema V is a function that maps each Vi to an element of U (V)); 
we use p v as a meta-variable to range over rows with schema V (or just p when 
V is clear from context). A table with schema V is a set of rows over V; we use 
T v for the set of tables with schema V, and I? v as a meta-variable to range 
over T v . When V is the empty set, we have only one row over V, which we 
denote with e; hence we have only two tables with schema 0, the empty one, 0, 
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and the singleton, {e}. We use l v to denote the largest table with schema V, 
i.e. the set of all rows with schema V. 

The table algebra is based on five primitive operators: union, complement, 
product, projection, and restriction, each carrying schema information. They 
correspond to the standard operations of relational algebra. 



The operators of table algebra: 







f? v 


U v f? ,v 


= def 


f? v u f? ,v 




c 


l v 






Co v ( J R v ) 


= def 


l V \i? V 




c 


l v 


V' 


D 

< 

II 

IS 


f? v 


X V ' V ' f?' v ' 


= def 


{p; p' 1 p e R 


v , p'eR' v '} 


c 


jvuv 


V' 


in 

< 


riv 


,/W 


— def 


y 1 d'e i v \ 


3 P e R v . p n p 


'} 


C l v ' 


FV{p,p') C V : 




r,'R V 


= def 


{p 1 p g R v , 


pX(p) ~ pX(p')} 


c 


l v 



i i 



The table union i? v U v f?' v is defined as the set-theoretic union of two tables 
with the same schema V. 

The table complement Co v (f? v ) is defined as the set-theoretic difference 

l v \f? v . 

If RY and f?' v are two tables whose schemas are disjoint, their table carte- 
sian product f? v x v,v f?' v is defined as the set containing all rows obtained 
by concatenating each row of f? v with each row of f? ,v . The result has schema 

VUV'. 

If V' is a subset of V, the projection 0v'^ V is defined as the set of all rows 
in RY restricted to the variables in V'. 

Let be the function that coincides with p v over V, and maps every p (]L V 
to p. If FV(p, p') C V, then the restriction ,RY is the set 

{p v | p V G f? V and pX(p) ~ p^p')} , 

where ~ is a label comparison operator, as in Section 0 

We will also use some derived operators, defined in the following table. 



Table algebra, derived operators: 



Ext%,(R v ) 




— def 


R w X V,V'\V 1 V'\V 


Cl v ' 


RV n v #V 




— def 


Co v (C'o v (f? v ) U v C'o v (f? ,v )) 


C l v 


RV m v ' v ' 


f?' v ' 


— def 


Extvuv(RY) n vuv ' ExtX^'{R ,w ' 


) c l VuV ' 


i? v ® v - v ' 


/d v ' 


= def 


Ext^uv (R v ) u vuv ' Ext%' u v'(R ,V ' 


) c l vuv ' 


II V' rV 




= def 


Co V, (IIv' CoY(RY)) 


c l v ' 



The operator RY X! V ' V f? ,v is well-known in the database field. It is called 
‘natural join’, and can be also defined as follows: the set containing all rows 
obtained by concatenating each row p in f? v with those rows p' in f? ,v such 
that p and p' coincide over V D V'. One important property of natural join 
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is that it always yields finite tables when is applied to finite tables, even if its 
definition uses the extension operator. Moreover, the optimization of join has 
been extensively studied; for this reason we will use this operator, rather than 
extension plus intersection, in the definition of our query evaluation procedure. 

Outer union i? v ® V ’ v i? ,v and co-projection i? v are useful for treating 
the dualized operators. 

Outer union is dual to join, in the following sense: 

i? v © v ' v 'i? ,v ' = Go VuV '(C'o v (i? v ) M v ’ v ' Co v '(i? ,v ')) 
Projection and co-projection are both left-inverse of extension: 

nv(^rfv'(* v )) = ^ v 

IIv (ExtV(RV)) = RV 

However, they represent two different ways of right-inverting extension: 

riv^ v = nK v ' i Extz\R ,v ') 2 i? v } 

Uv' = UK V ' I Ext%'(R' v ') C i? v } 



5.2 Query Evaluation 

We specify here an evaluation procedure Q(Q) P that, given a query Q and a row 
p that specifies a value for each free variable of Q , evaluates the corresponding 
information tree. A closed query “ from Q \= A select Q'” is evaluated by first 
evaluating Q to an information tree I. The pair /, A is then evaluated to yield 
a table i? v whose schema contains all the free variables in A. Finally, Q 1 is 
evaluated once for each row p of i? v ; all the resulting information trees are 
combined using |, to obtain the query result. This process is expressed in the 
last case of the table below. 

The first part of the table describes how a quadruple /, A, p v , 7 is evaluated 
by a binder evaluation procedure B to return a table with schema 5(A,V,7). 
The schema function S is specified in the table that follows, and enjoys the 
property that 5(A,V,e) = FV(A) \ V. Here 7 is an environment that maps 
recursion variables £ to functions from information trees to tables. We assume 
that 7 is always given together with a schema 7 mapping recursion variables to 
sets of variables V, such that 7(£) £ IT ■ 

The notation { (a: 1 — »n)} represents a table that contains only the row that 
maps x to n, and similarly for {(Ai —>•/)}. 



Binder and query evaluation 

1 



0 ) p y 7 

B(I,n[A\)pV n 
B(I,x[A]) p y 7 
B{I,x[A]) p v 7 



if I = 0 then {e} else 0 

if I = n[I'] then B(I' 1 A) p v 7 else 0 

H(/,p v (a;)[A]) p y 7 



if x£ V 
if x(f V 
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if I = n[I'] then {(inn)} ><{*}, 5(-4,v, 7 ) B(I',A)pV tJ else 0 
B(I,A\B) p v„ = 

U I r\i"=i} (W,A) p v, 7 M^M.v,7),5( B ,v,7) B(I",B) p v„) 

B(I, T) p v 7 = {e> 

B(I,^A) p v„ = Co s WM(B(I,A) p v„) 

B(I,A A B) p v t7 = B{I,A) P v 7 m 5 ^’ v ,7),s(s.v, 7) B(/,B) pV)7 

B(I,X) p v n = if I = p v (X) then {e} eZse 0 if A’ G V 



B(I,X) p v„ = {(A’i— >■/)} 



if A* G V 
if A’ ^ V 



5(0 3A\ A) p v„= Uf^ MX} B(I,A) p ^ 

B(I,3x.A) p v n = Uf { ^\ {x} l3(I,A) p ^ 

B(I,V-V') P ^= ^7~^0 l5(W ’ V ’ 5) 

S(7, M e^)„v 7 = F tt (AMGir^r s ^- 4 ’ v ^).A^.B(J,A) p v 7[ ^ M] )(I) 

B(I,Q p v„ = 7(000 



Q(^) P v = p v W 

Q(o) p v = 0 

Q(Q I QV = Q(Q) p v | Q(Q') P v 

Q(m[Q])p v = m[Q(Q) p v] 

QO-IODpv =p v (0[Q(Q)pv] 

Q(/(Q))pv = /(fi(Q)pv) 

Q(from Q\= A select Q') pV = let J = Q(Q) p v and R FV WW = B{I,A) p v e 

in Par p , GR Fv(A)\v Q(Q')(p v ;p') 



The schema function 5 

5 ( 0 , V,/ 1 ) = 0 

5(n[.A],V,r) = 5(d,V,r) 
5(x[^],V,r) = S(d,V,7)U(W\V) 

5(^|B,v,r) = 5(AV,r)u5(5,v,r) 
5(T, v, r) = 0 
5M,v,r) = 5(Av,r) 

5(AAB,V,7)= S(A,V,T) u5(B,V,r) 
5(A ’,V,r) = {A”} \ V 

5(3*. AV,f)= 5(AV,r)\{A”} 

5(3*. AV,r) = 5(AV,f)\{i} 
5(r^,/,V,T)= FV( V ,rf)\V 
S(^.A,V,n = S(A,V,r[£ H. 0]) 

5(0 v,r) = r(0 
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Since the rule for comparisons i] ~ rf is subtle, we expand here some special 
cases. 



Some special cases of comparison evaluation 
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- X’)pv n = 


{x,x } 1 {x,a/} 
u x~x' ± 


if 
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) 3 (I,Xr- 


- X’)pv n = 


< 7 {x} vr ,,!>> 
v (ar ) 


if 


x & V,a/ G V 




- a/)p v , 7 = 


rr 0 l 0 


if 


X G V,x' G V 


B{I,Xr- 


J n ) P v , 7 = 




if 


x£\ 


B(I, n ^ 
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" ™')p v ,7 = 


(*-e- if 


n ^ 


j n! then {e} else 0) 

i 



Lemma 1 . 

V, 7) = S(A, V, 7[C ^ S{tf.A, V, 7)]) 
6 (/,i) p v 7 er s(A ' v >i). 

Lemma 2. Let A be a formula , V be a set of variables , let El be a set {£7} * e/ of 
recursion variables that includes those that are free in A, and let 7 be a function 
defined over E such that, for every £», 7^) G XT T^^\ where 7 (£,) is 
disjoint from V. then: 

V P €i v ,/eiT.£(/,^) W7 = {p' | //ei™, /g[M] ( p , ;p) , 7(p ,)} 

where 'y(p) = \£:E .{I \ p € j(f)(I)} . 

The following proposition states that the query evaluation procedure is equiv- 
alent to the query semantics of Section 14.21 The proof uses Lemma 0 in the 
from-select case. 

Proposition 1. VQ, V D FV(Q), p v . Q(Q) p v = [Q] p v 

6 Conclusions and Future Directions 

We have defined a query language that operates on information represented 
as unordered trees. One can take different views of how information should be 
represented. For example as ordered trees, as in XML, or as unordered graphs, 
as in semistructured data. We believe that each choice of representation would 
lead to a (slightly different) logic and a query language along the lines described 
here. We are currently looking at some of these options. 

There are currently many proposals for regular pattern languages for semi- 
structured data, many having in common the desire to describe tree shapes and 
not just linear paths. Given the expressive power of general recursive formulas 
pf.A, we believe we can capture many such proposals, even though an important 
part of those proposals is to describe efficient matching techniques. 
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In this study we have exploited a subset of the ambient logic. The ambi- 
ent logic, and the calculus, also offer operators to specify and perform tree 
updates jZj. Possible connections with semistructured data updates should be 
explored. 

An implementation of TQL is currently being carried out, based on the im- 
plementation model we described. The current prototype can be used to query 
XML documents accessible through files or through web servers. 
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Abstract. We propose a formal framework for analyzing security proto- 
cols. This framework, which differs from previous logical methods based 
on the Dolev-Yao model, is based on a process calculus that captures 
probabilistic polynomial time. Protocols are written in a restricted form 
of 7r-calculus and security is expressed as a form or observational equiv- 
alence, a standard relation from programming language theory that in- 
volves quantifying over possible additional processes that might interact 
with the protocol. Using an asymptotic notion of probabilistic equiva- 
lence, we may relate observational equivalence to polynomial-time sta- 
tistical tests. Several example protocols have been analyzed. We believe 
that this framework offers the potential to codify and automate realistic 
forms of protocol analysis. In addition, our work raises some foundational 
problems for reasoning about probabilistic programs and systems. 



1 Summary 

This invited lecture for ESOP '01 will describe an approach to security protocol 
analysis based on a probabilistic polynomial-time process calculus and asymp- 
totic observational equivalence. The work has been carried out in collaboration 
with P. Lincoln, M. Mitchell, A. Scedrov, A. Ramanathan, and V. Teague. Some 
of the basic ideas are described in E.VI~.\IS!)A . with a description of a simpli- 
fied form of the process calculus appearing in |MMS98| and further example 
protocols considered in jLMMS99j . The closest technical precursor is the Abadi 
and Gordon spi-calculus [AG99IAG98J which uses observational equivalence and 
channel abstraction but does not involve probability or computational complex- 
ity bounds; subsequent related work is cited in Ml, for example. Prior work 
on CSP and security protocols, e.g., lliiis9_5_IScli9iil . also uses process calculus 
and security specifications in the form of equivalence or related approximation 
orderings on processes. Slides from this talk will be available on the author’s 
web site at http://www.stanford.edu/~jcm. 

2 Protocols 

Protocols based on cryptographic primitives are commonly used to protect access 
to computer systems and to protect transactions over the Internet. Two well- 
known examples are the Kerberos authentication scheme . used 
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to manage encrypted passwords, and the Secure Sockets Layer TKROfi . used 
by Internet browsers and servers to carry out secure internet transactions. In 
recent years, a variety of methods have developed for analyzing and reasoning 
about such protocols. These approaches include specialized logics such as BAN 
logic llBAN89| . special-purpose tools designed for cryptographic protocol analysis 
I1KMM94] . and theorem proving |L , au97alh , au97bl and model-checking methods 
using general purpose tools IILow9dlMea9filMMS97IKos95ISch9fil| . 

Although there are many differences among existing formal approaches, most 
use the same basic model of adversary capabilities. This model, apparently de- 
rived from }DY83| and views expressed in ; N^78 ] . treats cryptographic opera- 
tions as “black-box” primitives. For example, encryption is generally considered 
a primitive operation, with plaintext and ciphertext treated as atomic data that 
cannot be decomposed into sequences of bits. In most uses of this model, as ex- 
plained in |MMS97IFau97alSch96| , there are specific rules for how an adversary 
can learn new information. For example, if the decryption key is sent over the 
network “in the clear” , it can be learned by the adversary. However, it is not 
possible for the adversary to learn the plaintext of an encrypted message unless 
the entire decryption key has already been learned. Generally, the adversary is 
treated as a nondeterministic process that may attempt any possible attack, and 
a protocol is considered secure if no possible interleaving of actions results in a 
security breach. The two basic assumptions of this model, perfect cryptography 
and nondeterministic adversary, provide an idealized setting in which protocol 
analysis becomes relatively tractable. 

While there have been significant accomplishments using this model, the 
assumptions inherent in the standard model also make it possible to “verify” 
protocols that are in fact susceptible to attack. For example, the model does 
not allow the adversary to learn a decryption key by guessing, since then some 
nondeterministic execution would allow a correct guess, and all protocols relying 
on encryption would be broken. However, in some real cases, adversaries can 
learn some bits of a key by statistical analysis, and can then exhaustively search 
the remaining (smaller) portion of the key space. Such an attack is simply not 
considered by the model described above, since it requires both knowledge of the 
particular encryption function involved and also the use of probabilistic methods. 

Our goal is to develop an analysis framework that can be used to explore 
interactions between protocols and cryptographic primitives. We are also in- 
terested in devising specifications of cryptographic primitives such as oblivi- 
ous transfer and selective decommittment. Our framework uses a language for 
defining communicating probabilistic polynomial-time processes |MMS98| . We 
restrict processes to probabilistic polynomial time since the adversary is rep- 
resented by an arbitrary context, written in the process calculus. Limiting the 
running time of an adversary allows us to lift other restrictions on the behavior of 
an adversary. Specifically, an adversary may send randomly chosen messages, or 
perform arbitrary probabilistic polynomial-time computation on messages over- 
heard on the network. In addition, we treat messages as sequences of bits and 
allow specific encryption functions such as RSA or DES to be written in full as 
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part of a protocol. An important feature of this framework is that we can analyze 
probabilistic as well as deterministic encryption functions and protocols. With- 
out a probabilistic framework, it would not be possible to analyze an encryption 
function such as ElGamal IE1G85II . for example, for which a single plaintext may 
have more than one ciphertext. 

Security properties of a protocol P may be formulated by writing an idealized 
protocol Q so that, intuitively, for any adversary M, the interactions between M 
and P have the same observable behavior as the interactions between M and Q. 
This intuitive description may be formalized by using observational equivalence 
(also called observational congruence), a standard notion from the study of pro- 
gramming languages. Namely, two processes (such as two protocols) P and Q 
are observationally equivalent, written P ~ Q, if any program C[P) containing P 
has the same observable behavior as the program C[Q\ with Q replacing P. The 
reason observational equivalence is applicable to security analysis is that it in- 
volves quantifying over all possible adversaries, represented by the environments, 
that might interact with the protocol participants. In our asymptotic formula- 
tion, observational equivalence between probabilistic polynomial-time processes 
coincides with the traditional notion of indistinguishability by polynomial-time 
statistical tests iLuhSfl&ofia . a standard way of characterizing cryptographi- 
cally strong pseudo-random number generators. 

The remainder of this short document presents the key definitions, as refer- 
ence for the author’s invited talk. 

3 Process Calculus 

The protocol language consists of a set of terms, or sequential expressions that 
do not perform any communication, and processes, which can communicate with 
one another. The process portion of the language is a restriction of standard tt- 
calculus | .VI rW!)2j . All computation done by a process is expressed using terms. 
Since our goal is to model probabilistic polynomial-time adversaries by quanti- 
fying over processes definable in our language, it is essential that all functions 
definable by terms lie in probabilistic polynomial time. Although we use pseudo- 
code to write terms in this paper, we have developed an applied, simply-typed 
lambda calculus which exactly captures the probabilistic polynomial-time terms 




The syntax of processes is given by the following grammar: 



Polynomials appear explicitly in the syntax of processes in two places, in 
channel names and in replication. In a channel name c 9 (| n |), the polynomial 



P ::= 0 



%(M)'( P ) 
c q{\n\)i, x ) -P 

c q(\n\)(T) 

[T = T].P 
P | P 



(termination) 
(private channel) 



(input) 

(output) 

(match) 




(parallel composition) 
(g(|n|)-fold replication) 
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q(\n\) associated with the channel c indicates that for some value n of the security 
parameter, channel c can carry values of q(\n\) bits or fewer. This restriction on 
the size of natural numbers that are communicated from one process to another 
is needed to maintain the polynomial-time restriction on process computations. 
Replication \ q (\ n \ )-P results in g(|n|) copies of process P, where n is again the 
security parameter. For simplicity, after fixing n when we evaluate a process 
P, we replace all subexpressions of P of the form ! g (| n |).i? with g(|n|) copies of 
R in parallel. We also assume that all channel names and variable names are 
a-renamed apart. 

The operational semantics of this process calculus is fairly intricate, due 
to probabilistic considerations and the desire to keep communication on a pri- 
vate channel from biasing the probabilities associated with externally observable 
communication on public channels. In brief, executing a process step begins with 
outer evaluation of any terms. In a process [Ti = T 2 ].P, for example, we eval- 
uate terms T\ and T 2 before possibly performing any communication inside P. 
Similarly, execution of c 9 (|n|)( p ) begins with the evaluation of the term T, and 
execution of P \ Q with the outer-evaluation of both P and Q. 

Once a process is outer-evaluated, a set of eligible communication pairs is 
selected. The set of schedulable processes S(P) is defined inductively by 

S( 0) = 0 

SK CM) •(<?)) =S(Q) 

S i C p(\n\){T)) = {c p (|„|)(T}} 

5(Qi|Q 2 ) =5(Qi)U5(Q 2 ) 

Since P is outer-evaluated prior to computing S(P), we do not need to consider 
the case P = [T x = T 2 ].Q. Note that every process in S(P) is either waiting for 
input or ready to output. The set of communication triples C(P) is 

{(Pi,P 2 ,Qp 1 ,p 2 [ ])| Pi € S(P) 1 P 1 = c p (|„|)(a),P 2 = Cp( |„|)(a;).i?, P = 

Q r^,p 2 [P\ ■, Pi]} 

and the set of eligible processes E{P) is defined by 

= f C '( p )lprivate channels if there is a possible private communication 
\ c '( p )lpubiic channels otherwise. 

The reason for this definition, explained intuitively in j I ,.VI VISiJTi] , is to keep 
communication on a private channel from biasing the probabilities associated 
with externally observable communication on public channels. Once a set of 
eligible processes have been determined, a computation step of P proceeds by 
selecting one communication triple from E{P ) at random and performing the 
resulting communication step. 
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4 Equivalence 

An observation is a test on a specific public channel for a specific natural number. 
More precisely, let Obs be the set of all pairs (i, c p (|„p) where i is a natural num- 
ber and c p (| n |) is a public channel. If, during an evaluation of process expression 
P, the scheduler selects the communication triple 



( c p(|n|)(*)> c p{\n\)[x) .P , Qcp(| n |)<i>,Cp(|„|)(a:).P') 

we will say that the observable (i, c p (|„|)) G Obs occurs and write P ~> (i, c p (| n p). 

A process P may contain the security parameter n, as described above. We 
will write P m to signify that the parameter n is assigned the natural number m. 
A process family V is the set (Pi | isN). Since contexts may contain the process 
parameter n, we can define the context family C[ } analogously. 

If V and Q are two process families, then V and Q are observationally equiv- 
alent, written write that V = Q, if 

\/q(x).\/C[ ].Vo e 0bs3n o .\/n > n a : 

|Prob(C[P] mo)- Prob(C[Q] o)| < — ^ 

q(n) 

where C[ ] indicates a context family and q(x) an everywhere-positive polyno- 
mial. 

It is straightforward to check that = is an equivalence relation. Moreover, we 
believe that this formal definition reasonably models the ability to distinguish 
two processes by feasible intervention and observation. If P = {P n }n> o is a 
scheme for generating pseudorandom sequences of bits, and Q = {Q n }n> o con- 
sists of processes that generate truly random bits (e.g., by calls to our built-in 
random-bit primitive), then our definition of observational equivalence corre- 
sponds to a standard notion from the study of pseudorandomness and cryptog- 
raphy (see, e.g., |ILub9(ilYao821l 'l. Specifically, P ~ Q iff P and Q pass the same 
polynomial-time statistical tests. 



5 Applications and Future Directions 

An example authentication protocol, proposed by Bellare and Rogaway |[BR.94j . 
is discussed in |LMMS99j . However, the proof of security of this protocol that 
is presented in [ILMMS99] is ad hoc, and relies on specific syntactic similarities 
between the protocol and its specification. In the future, we hope to develop more 
powerful systematic proof methods for observational congruence. Since there has 
been little prior work on complexity-bounded probabilistic process formalisms 
and asymptotic equivalence, one of our near-term goals is to better understand 
the forms of probabilistic reasoning that would be needed to carry out more 
rigorous protocol analysis. 
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Abstract. The Java JDK 1.2 Security Architecture includes a dynamic 
mechanism for enforcing access control checks, so-called stack inspec- 
tion. This paper studies type systems which can statically guarantee the 
success of these checks. We develop these systems using a new, system- 
atic methodology: we show that the security-passing style translation, 
proposed by Wallach and Felten as a dynamic implementation tech- 
nique, also gives rise to static security- aware type systems, by compo- 
sition with conventional type systems. To define the latter, we use the 
general HM(X) framework, and easily construct several constraint- and 
unification-based type systems. They offer significant improvements on 
a previous type system for JDK access control, both in terms of expres- 
siveness and in terms of readability of inferred type specifications. 



1 Introduction 

The Java Security Architecture j2|, found in JDK 1.2 and later, includes mech- 
anisms to protect systems from operations performed by untrusted code. These 
access control decisions are enforced by dynamic checks. Our goal is to make 
some or all of these decisions statically , by extensions to the type system. Thus, 
access control violations will be caught at compile-time rather than run-time. 
Furthermore, types (whether inferred or programmer-supplied) will constitute a 
specification of the security policy. 



A Brief Review of the JDK Security Architecture. For lack of space, we 
cover the JDK security architecture in a cursory manner here; see {211. JI8I for 
more detailed background. To use the access control system, the programmer 
adds doPrivileged and checkPrivilege commands to the code. At run-time, 
a doPrivileged command adds a flag to the current stack frame, enabling a 
particular privileged operation. The flag is implicitly eliminated when the frame 
is popped. When a privilege is checked via a checkPrivilege command, the 
stack frames are searched most to least recent. If a frame is encountered with 
the desired flag, the search stops and the check succeeds. Additionally, each stack 
frame is annotated with its owner (the owner of the method being invoked), and 
all stack frames searched by the above algorithm must be owned by some prin- 
cipal authorized for the privilege being checked. This keeps illicit code, invoked 
by the trusted codebase when doPrivileged is on the stack, from performing 
the privileged operation. 

D. Sands (Ed.): ESOP 2001, LNCS 2028, pp. 80-1151 2001. 

(c) Springer- Verlag Berlin Heidelberg 2001 
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Our Framework. This paper follows up on an initial access control type system 
presented by the last two authors in fj] and places emphasis on a more modular 
approach to type system construction. The previous paper developed the security 
type system ab initio. In this paper, we reduce the security typing problem to a 
conventional typing problem using a translation-based method inspired by jS|. 
We use a standard language of row types |7| to describe sets of privileges. We also 
re-use the HM(X) framework |319j . which allows a wide variety of type systems 
to be defined in a single stroke, saves some proof effort, and (most importantly) 
shows that our custom type systems arise naturally out of a standard one. 

In addition to these methodological enhancements, this paper improves upon 
its predecessor in several other ways. In particular, JBJ was based on subtyping 
constraints, whereas one of the type systems presented here uses row unification 
alone; this makes it more efficient and leads to more concise types. Also, the 
calculus studied in this paper allows for dynamic test-and-branch on whether a 
privilege is enabled. Lastly, because our new approach relies on HM(X), we can 
easily provide let-polymorphism. 

We begin by defining a simplified model of the Java JDK 1.2 security archi- 
tecture. It is a A-calculus, called A sec , equipped with a non-standard operational 
semantics that includes a specification of stack inspection. In order to construct 
a static type system for A sec , we translate it into a standard A-calculus, called 
A se t- The translation is a security-passing style transformation m- it imple- 
ments stack inspection by passing around sets of privileges at run-time. For this 
purpose, A S et is equipped with built-in notions of set and set operations. 

Then, we define a type system for A se t- Because A se t is a standard A-calculus, 
we are able to define our type system as a simple instance of the HM(X) frame- 
work j3|. In fact, by using this framework a whole family of type systems may be 
succinctly defined, each with different costs and benefits. In order to give precise 
types to A S et’s built-in set operations, our instance uses set types, defined as a 
simplification of Remy’s record types 0. 

Lastly, we show that any type system for A se t gives rise through the transla- 
tion to a type system for A sec - The latter’s correctness follows immediately from 
the former’s, provided the translation itself is correct. This is quite easy to show, 
since the property does not involve types at all. 



2 The Source Language A sec 

This section defines A sec , a simplified model of the JDK 1.2 security architecture. 
It is a A-calculus equipped with a notion of code ownership and with constructs 
for enabling or checking privileges. Its grammar is given in Fig.Q 

We assume given notions of principals and resources (the latter also known 
as privileges) , taken from arbitrary sets V and 7Z. We use p and r to range over 
principals and resources, respectively, and P and R to range over sets thereof. 

We assume given a fixed access credentials list A. It is a function which maps 
every principal p GV to a subset of 1Z. We let denote its “inverse”, that is, 
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p £P,P cp 
r G TZ, R C. TZ 
deP->2 K 



principals 
resources 
access credentials 



v ::= Xx.f values 

e ::= x \ Xx.f \ e e | let x = e in e | letprivrine | expressions 

checkpriv r for e | testpriv r then e else e | / 

/ :\= p.e signed expressions 

E [] | JJe | v E | let x = Eine \ evaluation contexts 

letprivrini? | p.E 



Fig. 1. Grammar for A sec 



the function which maps a resource r£lZ to {p£V\r£ A(p)}. Without loss of 
generality, we assume the existence of a fixed principal po such that A(po) = 0. 

A signed expression p.e behaves as the expression e endowed with the au- 
thority of principal p. Notice how the body of every A-abstraction is required to 
be a signed expression - thus, every piece of code must be vouched for by some 
principal. The construct letpriv r in e allows an authorized principal to enable the 
use of a resource r within the expression e. The construct checkpriv r for e asserts 
that the use of r is currently enabled. If r is indeed enabled, e is evaluated; oth- 
erwise, execution fails. The construct testpriv r then ei else dynamically tests 
whether r is enabled, branching to ei or e 2 if this holds or fails, respectively. 

2.1 Stack Inspection 

The JDK 1.2 determines whether a resource is enabled by literally examining the 
runtime stack, hence the name stack inspection. We give a simple specification 
of this process by noticing that stacks are implicitly contained in evaluation 
contexts, whose grammar is defined in Fig. D Indeed, a context defines a path 
from the term’s root down to its active redex, along which one finds exactly the 
security annotations which the JDK 1.2 would maintain on the stack, that is, 
code owners p and enabled resources r. 

To formalize this idea, we associate a finite string of principals and resources, 
called a stack, to every evaluation context E. The right-most letters in the string 
correspond to the most recent stack frames. 

stack([]) = e stack(£’e) = stack(K) 

stack(v E) = stack(£ l ) stack(let x = E in e) = stack(K) 
stack(letpriv r in E) = r.stack(K) stack (p.E) = p.stack(K) 

Then, Fig. 0 defines stack inspection, with S b r meaning access to resource r is 
allowed by stack S, and S \~ P meaning some principal in P is the most recent 
owner on S. This specification corresponds roughly to Wallach ’s E3 P- 71], We 
write E\- r for stack(K) b r. 
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r £ A(p) S b r 


Shr 


Sb A _1 (r) 


SbP 


p £ P 


S.p b r 


S.r' b r 


S.r b r 


S.r b P 


S.p b P 



Fig. 2. Stack inspection algorithm 



2.2 Operational Semantics for A sec 

The operational semantics of A sec is defined by the following reduction rules: 

E[(Xx.f)v] -*• E[f[v/x}\ 

E[\etx = nine] — > £7[e[v/a;]] 
if[checkprivrfore] — > E[e] if E b r 

-E[testpriv r then ei else e 2 ] —> E[e i] if E b r 

if[testpriv r then ei else e 2 ] —> E[e 2 ] if ->(E b r) 

if[letprivrinv] — > iffu] 

-E[p.u] — > E[v\ 

The first two rules are standard. The next rule allows checkpriv r for e to 
reduce into e only if stack inspection succeeds (as expressed by the side condi- 
tion lihr); otherwise, execution is blocked. The following two rules use stack 
inspection in a similar way to determine how to reduce testpriv r then ei elsee 2 ; 
however, they never cause execution to fail. The last two rules state that secu- 
rity annotations become unnecessary once the expression they enclose has been 
reduced to a value. In a Java virtual machine, these rules would be implemented 
simply by popping stack frames (and the security annotations they contain) after 
executing a method. 

This operational semantics constitutes a concise, formal description of Java 
stack inspection in a higher-order setting. It is easy to check that every closed 
term either is a value, or is reducible, or is of the form if [checkpriv r for e] where 
-<{E b r). Terms of the third category are stuck ; they represent access control 
violations. An expression e is said to go wrong if and only if e — >* e ' , where e' is 
a stuck expression, holds. 



3 The Target Calculus A set 

We now define a standard calculus, A set , to be used as the target of our transla- 
tion. It is a A-calculus equipped with a number of constants which provide set 
operations, and is given in Fig. 0 We will use e.r, e V R and e A R as syntactic 
sugar for (, r e), (V^e) and (A^e), respectively. 

The constant R represents a constant set. The construct e.r asserts that r 
is an element of the set denoted by e; its execution fails if that is not the case. 
The construct eVf? (resp. eAR) allows computing the union (resp. intersection) 
of the set denoted by e with a constant set R. Lastly, the expression l r efg 
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e : 


= x | v | e e | let x = e in e 


expressions 


v : 


:= Xx.e | R | . r | ?r | Vi? | A r 


values 


E 


::= [] | E e \ v E \ let x = E in e 


evaluation contexts 



Fig. 3. Grammar for A se t 



dynamically tests whether r belongs to the set R denoted by e, and accordingly 
invokes / or < 7 , passing R to it. The operational semantics for A set is as follows: 

(Xx.e) v —> e[v/x\ 
let a; = fine e[v/x\ 



R.r — > R 


if r £ R 


? r R^Xf.Xg.(fR) 


if r £ R 


? r R -a Xf.Xg.(g R) 


if r ^ R 


R\ v R2 — y Ri u R2 




R\ a R2 — y R± n R2 




E[e\ -> E[e'} 


if e — > e' 



Again, an expression e is said to go wrong if and only if e — >* e\ where e' is a 
stuck expression, holds. 



4 Source-to- Target Translation 

A translation of A sec into A se t is defined in Fig.0. The distinguished identifiers 
s and _ are assumed not to appear in source expressions. Notice that s may ap- 
pear free in translated expressions. Translating an (unsigned) expression requires 
specifying the current principal p. 

One will often wish to translate an expression under minimal hypotheses, i.e. 
under the initial principal po and a void security context. To do so, we define 
d e D = [e]p o [ 0 / s ]- Notice that s does not appear free in fle). If e is closed, then 
so is (| e D . 



Mp = * 

IXx.fjp = A*. As. I/] 

[ei e 2 ] p = [ei| p [e 2 ] p s 
[let x = ei in e 2 ] p = let x = [ei J p in [e 2 J p 

[letpriv r in e] p = let s = s V ({r} n A(p)) in [e] p 
[checkpriv r for e] p = let _ = s.r in [e] p 
[testpriv r then ei else e 2 ] p = ? r s (As.[ei] p ) (As.[e 2 J p ) 

i/Ip = [/: 

[p.ej = let s = s A A(p) in [e] p 



Fig. 4. Source-to-Target Translation 
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The idea behind the translation is simple: the variable s is bound at all times 
to the set of currently enabled resources. Every function accepts s as an extra pa- 
rameter, because it must execute within its caller’s security context. As a result, 
every function call has s as its second parameter. The constructs letprivrine 
and p.e cause s to be locally bound to a new value, reflecting the new security 
context; more specifically, the former enables r, while the latter disables all priv- 
ileges not in A(p). The constructs checkpriv r for e and testpriv r then e\ else ei 
are implemented simply by looking up the current value of s. In the latter, s is 
re-bound, within each branch, to the same value. This may appear superfluous 
at first sight, but has an important impact on typing, because it allows s to be 
given a different (more precise) type within each branch. 

This translation can be viewed as a generalization of Wallach’s security- 
passing style transformation m to a higher-order setting. Whereas they advo- 
cated this idea as an implementation technique, with efficiency in mind, we use 
it only as a vehicle in the proof of our type systems. Here, efficiency is not at 
stake. Our objective is only to define a correct translation, that is, to prove the 
following: 

Theorem 4.1. If e — >* v, then (e|) — >* (u). If e goes wrong, then (e) goes 
wrong. If e diverges, then ( e ) diverges. 

The proof is divided in two steps. First, we define a new stack inspection 
algorithm, which walks the stack forward instead of backward, and computes, 
at each step, the set of currently enabled resources. Then, we show that the 
translation implements this algorithm, interleaved with the actual code. Both 
proof steps are straightforward, and we omit them here for brevity. 

5 Types for A set 

We define a type system for the target calculus as an instance of the parametric 
framework HM(X) P0. HM(X) is a generic type system in the Hindley-Milner 
tradition, parameterized by an abstract constraint system X. Sect. 13. II briefly 
recalls its definition. Sect. l>d defines a specific constraint system called SETS, 
yielding the type system HM(SETS). Sect. I0.5l extends HM(SETS) to the entire 
language A se t by assigning types to its primitive operations. Sect. 15. 4l stat.es type 
safety results and discusses a couple of choices. 

5.1 The System HM(A) 

The system HM(X) is parameterized by a sound term constraint system X , i.e. 
by notions of types r, constraints C, and constraint entailment lb, which must 
satisfy a number of axioms 0. 

Then, a type scheme is a triple of a set of quantifiers d, a constraint G , and 
a type r (which, in this paper, must be of kind Type; see Sect. IQ.tfl) . written 
a ::= \/a[C].T. A type environment r is a partial mapping of program variables 
to type schemes. A judgement is a quadruple of a satisfiable constraint C , a 
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Var 

r(x) = \/a[D].r C\^3a.D 


Sub 

C, r b e : r C lb r < t 


C,T hx: \/a[D\.r 


C,r e : t 


Abs 

C,(r;i:r)he:T 


App 

C, r b ei : T 2 — > t (7, T b e 2 : T 2 


C,r b Xx.e : t -> t' 


C,r b ei e 2 : t 


Let 

C, T b ei : cr C, (T; a; : cr) b e 2 : r 


V Intro 

C A D, F h e : t aHtv{C,r) = 0 


C, r b let x = ei in e 2 : t 


C A3a.D,r e :Va[D].r 


V Elim 

C,T be: Vq[D].t 


3 Intro 

C, F b e : cr all fv(T, a) = 0 


C A .D, T b e : t 


3a. C, The : a 



Fig. 5. The system HM(X) 



T 


:= a,P, 


. . | t — > t | {r} | r : t ; t \ dr \ c 


types 


C 


:= NA | 


Pre | Abs | Either 


capabilities 


c 


:= true 


| C A C | 3a. C |r = T|T<r|ifc<r then r < t 


constraints 



Fig. 6. SETS Grammar 



type environment T, an expression e and a type scheme cr, written C, T b e : cr, 
derivable using the rules of Fig. 0 These rules correspond to those given in |9|. 

The following type safety theorem is proven in J3] with respect to a denota- 
tional presentation of the call-by- value A-calculus with let. We have proved a 
syntactic version of it, in the style of m, which better suits our needs. 

Theorem 5.1. If C,T \- e : a holds, then e does not go wrong. 

5.2 The Constraint System SETS 

In order to give precise types to the primitive set operations in A se t, we need 
specific types and constraints. Together with their logical interpretation, which 
defines their meaning, these form a constraint system called SETS. 

The syntax of types and constraints is defined in Fig. 0 The type language 
features a set type constructor {•}, the two standard row constructors 0, and 
four capability constructors. Capabilities tell whether a given element may ap- 
pear in a set (Pre), may not appear in it (Abs), may or may not appear in 
it (Either), or whether this information is irrelevant, because the set itself is 
unavailable (NA). For instance, the singleton set {r} will be one (and the only) 
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a 6 Vfc t, t : Type. 


t : 

r : Row 0 r 


Cap r 0 R 

• ROW i^u{r} 


t : Cap 


a : k t — y t : Type 


{t} : Type (r : 


t ; t) : Rowr 


dr : Rowr 




F Ci,C 2 


b C 


r, t : k 


c : Cap h true 


hCiAC 2 


b 3 a.C 


b r = t 




b if CT then Ci 




b t < t' 



Fig. 7. Finding rules 



value of type { 7 ' : Pre ; 9Abs}. The constraint language offers standard equality 
and subtyping constraints, as well as a form of conditional constraints. Sample 
uses of these types and constraints will be shown in Sect. 15.31 

To ensure that only meaningful types and constraints can be built, we im- 
mediately equip them with kinds , defined by k ::= Cap \ Rowr \ Type , where R 
ranges over finite subsets of TZ. For every kind k , we assume given a distinct, de- 
numerable set of type variables Vj, . We use a, /3, 7, . . . to represent type variables. 
From here on, we consider only well-kinded types and constraints, as defined in 
Fig. □ The purpose of these rules is to guarantee that every constraint has a 
well-defined interpretation within our model, whose definition follows. 

To every kind k , we associate a mathematical structure [fc]. [Cap] is the set 
of all four capabilities. Given a finite set of resources R Q7Z, [Row#] is the set 
of total, almost constant functions from 7 Z\R into [Cap]. (A function is almost 
constant if it is constant except on a finite number of inputs.) In short, Row a is 
the kind of rows which do not carry the fields mentioned in R ; Row 0 is the kind of 
complete rows. [Type] is the free algebra generated by the constructors — >, with 
signature [Type] x [Type] — > [Type], and {•}, with signature [Row 0 ] -* [Type]. 

Each of these structures is then equipped with an ordering. Here, a choice has 
to be made. If we do not wish to allow subtyping, we merely define the ordering 
on every [fc] as equality. Otherwise, we proceed as follows. First, a lattice over 
[Cap] is defined, whose least (resp. greatest) element is NA (resp. Either), and 
where Abs and Pre are incomparable. This ordering is then extended, point- 
wise and covariantly, to every [Row#]. Finally, it is extended inductively to 
[Type] by viewing the constructor {•} as covariant, and the constructor — > as 
contravariant (resp. covariant) in its first (resp. second) argument. 

We may now give the interpretation of types and constraints within the 
model. It is parameterized by an assignment p, i.e. a function which, for every 
kind fc, maps V& into [fc]. The interpretation of types is obtained by extending 
p so as to map every type of kind k to an element of [fc], as follows: 

p(r -b> t') = p(r) -t p(r') p{ {t}) = (p(r)} 

p{r : r ; r')(r) = p(r) p(r : r ; /)(/) = p(r'){r') (r ^ r') 

p(dr)(r) = p(r) p(c) = c 
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Fig. 8. Interpretation of constraints 



Fig. El defines the constraint satisfaction predicate • b ■, whose arguments are an 
assignment p and a constraint C . (The notation p = p' [ct] means that p and p' 
coincide except possibly on a.) Entailment is defined as usual: C lb C (read: 
C entails C) holds iff, for every assignment p, p\r C implies p\~ C' . 

We refer to the type and constraint logic, together with its interpretation, 
as SETS. More precisely, we have defined two logics, where < is interpreted as 
either equality or as a non-trivial subtype ordering. We will refer to them as 
SETS = and SETS-, respectively. Both are sound term constraint systems Q. 

5.3 Dealing with the Primitive Operations in A set 

The typing rules of HM(X) cover only the A-calculus with let. To extend 
HM(SETS) to the whole language A se t, we must assign types to its primitive 
operations. Let us define an initial type environment T\ as follows: 

R : {R : Pre ; <9Abs} 

. r : V/3.{r : Pre ; (3} — > {r : Pre ; /3} 

Vfl : \//3j.{R : j ; (3} -4 {R : Pre ; 0} 

A r : V/Ty .{i? : 7 ; 0} -4 {R : 7 ; <9Abs} 

? r : \/a/3j.{r : 7 ; (3} — > ({r : Pre ; 0} — > a) — > ({r : Abs ; 0} — > a) — > a 

Here, a, 0 7 range over type variables of kind Type , I?ow*, Cap , respectively. 
We abuse notation: if R is {ri, . . . ,r„}, then R : c denotes 77 : c; . . . ; r n : c, 
and R : 7 denotes 77 : 71 ; . . . ; r n : 7„. 

None of the type schemes in carry constraints. If we wish to take advantage 
of conditional constraints, we must refine the type of l r . Let T2 be the initial 
type environment obtained by replacing the last binding in T\ with 

? r : Vd^7 [C].{r : 7 ; 0} -S> ({r : Pre ; 0} -> 07) —I ({r : Abs ; 0} -HI2) 4 a 
where C = if Pre < 7 then (3 < [3 1 A if Abs < 7 then (3 < 0 
A if Pre < 7 then 07 < a A if Abs < 7 then 0:2 < a 

Here, the input and output of each branch (represented by 0 and 07, respec- 
tively) are linked to the input and output of the whole construct (represented 
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by {3 and a) through conditional constraints. Intuitively, this means that the 
security requirements and the return type of a branch may be entirely ignored 
unless the branch seems liable to be taken. (For more background on conditional 
constraints, the reader is referred to hho 

5.4 The Type Systems Sf el 

Sect. 15.21 describes two constraint systems, SETS = and SETS-. Sect. 13. 31 defines 
two initial typing environments, T) and T 2 . These choices give rise to four related 
type systems, which we refer to as S[ e , where rel and i range over {=, <} and 
{1, 2}, respectively. Each of them offers a different compromise between accuracy, 
readability and cost of analysis. In each case, Theorem 15.1 1 ma.v be extended to 
the entire language A set by proving a simple 5-typability m lemma, i.e. by 
checking that F, correctly describes the behavior of the primitive operations. 
The proofs are straightforward and are not given here. 

Despite sharing a common formalism, these systems may call for vastly dif- 
ferent implementations. Indeed, every instance of HM(X) must come with a 
constraint resolution algorithm. <Sf is a simple extension of the Hindley-Milner 
type system with rows, and may be implemented using unification [6 . S 2 is sim- 
ilar, but requires conditional (i.e. delayed) unification constraints, adding some 
complexity to the implementation. Sf and Sf require maintaining subtyping 
constraints, usually leading to complex implementations. 

In the following, we lack the space to describe all four variants. Therefore, 
we will focus on iS)f. Because it is based on unification, it is efficient, easy to 
implement, and yields readable types. We conjecture that, thanks to the power 
of row polymorphism, it is flexible enough for many practical uses (see Sect. 1731 ) . 

6 Types for A sec 

6.1 Definition 

Sect. 0 defined a type system, S[ el , for A se t- Sect. 0 defined a translation of 
A sec into A se t- Composing the two automatically gives rise to a type system 
for Asec> also called Sf el for simplicity, whose safety is a direct consequence of 
Theorems 14. 1 1 and 13 . 1 1 

Definition 6.1. Let e be a closed A sec expression. By definition, C, T h e : a 
holds if and only if C, T b ( e D : er holds. 

Theorem 6.2. If C . T \~ e : a holds, then e does not go wrong. 

Turning type safety into a trivial corollary was the main motivation for bas- 
ing our approach on a translation. Indeed, because Theorem 14. II concerns un- 
typed terms, its proof is straightforward. (The (5-typability lemmas mentioned 
in Sect. 13.31 do involve types, but are typically very simple.) A direct type safety 
proof would be non-trivial and would duplicate most of the steps involved in 
proving HM(A') correct. 
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6.2 Reformulation: Derived Type Systems 

Definition l(>. 1 1 although simple, is not a direct definition of typing for A sec - 
We thus will give rules which allow typing A sec expressions without explicitly 
translating them into A se t- These so-called derived rules can be obtained in 
a rather systematic way from the definition of S and the definition of the 
translation. (In fact, it would be interesting to formally automate the process.) 

In these rules, the symbols r and <; range over types of kind Type ; more specif- 
ically, s is used to represent some security context, i.e. a set of available resources. 
The symbols p and tp range over types of kind Row * and Cap , respectively. The 
* symbol in the rules indicates an irrelevant principal. In the source-to-target 
translation, all functions are given an additional parameter, yielding types of 
the form t\ — > — > T2- To recover the more familiar and appealing notation 

proposed in @, we define the macro ti 12 = de f t\ — > C2 — > t~2- 

Fig. Ogives derived rules for , the simplest of our type systems. There, all 
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Fig. 9. Typing rules for A se c derived from 1 S 1 
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constraints are equations. As a result, all type information can be represented 
in term form, rather than in constraint form We exploit this fact to give a 
simple presentation of the derived rules. Type schemes have the form Vd.r, and 
judgements have the form p, r b e : a. 

To check that these derived rules are correct, we prove the following lemmas: 

Lemma 6.3. p, h e : a holds iff true, (/\; T; s : <j) b [e] p : a holds. 



Lemma 6.4. po, {<9Abs}, T b e : er holds iff true, (Tj; T) b (j e D : cr holds. 

Together, Theorem It >. '4 1 and Lemma lh.4l show that, if a closed A sec expression 
e is well-typed according to the rules of Fig.|3 under the initial principal po and 
the empty security context {9Abs}, then e cannot go wrong. 

Derived rules for each member of the SJ el family can be given in a similar 
way. The same process can also be used to yield type inference rules, rather than 
the logical typing rules shown here. 



7 Examples 

7.1 Basic Use of Security Checks 

Imagine an operating system with two kinds of processes, root processes and user 
processes. Killing a user process is always allowed, while killing a root process 
requires the privilege killing. At least one distinguished principal root has this 
privilege. The system functions which perform the killing are implemented by 
root , as follows: 



kill — A (p : process) .root. checkpriv killing for . . . () - kill the process 

killlfUser = A (p : process) .root. . . . () - kill the process if it is user-level 



In system Jq , these functions receive the following (most general) types: 



kill : V (3 .process 



{killing : Pre ; (3} 



» unit 



m. 



killlfUser : V (3. process > unit 



The first function can be called only if it can be statically proven that the 
privilege killing is enabled. The second one, on the other hand, can be called at 
any time, but will never kill a root process. To complement these functions, it 
may be desirable to define a function which provides a “best attempt” given the 
current (dynamic) security context. This may be done by dynamically checking 
whether the privilege is enabled, then calling the appropriate function: 

tryKill = A (p : process) .root. 

testpriv killing then kill(p) else killlfUseffp) 
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This function is well- typed in system iSjA Indeed, within the first branch of 
the testpriv construct, it is statically known that the privilege killing must be 
enabled; this is why the sub-expression kill(p) is well-typed. The inferred type 
shows that tryKill does not have any security requirements: 

tryKill : V/3 . process unit 



7.2 Security Wrappers 

A library writer often needs to surround numerous internal functions with “boil- 
erplate” security code before making them accessible. To avoid redundancy, it 
seems desirable to allow the definition of generic security wrappers. When applied 
to a function, a wrapper returns a new function which has the same computa- 
tional meaning but different security requirements. 

Assume given a principal p such that A(p) = {r, s}. Here are two wrappers 
likely to be of use to this principal: 



enable r = A/.p.Aaxp.letprivrin/x 
require r = A/.p.Ax.p.checkprivrfor/x 



In system , these wrappers receive the following (most general) types: 

. {r:Pre; s:7i ; 9 Abs} {/ 3 i} . {7:72 ; 8:71 ; fa} , 

enable r : V . . . .(cci > a 2 ) >• (cm >• cm) 

. {r:Pre ; s:7i ; 9 Abs} . {/ 3 i} , {r:Pre ; s:7i ; 0 2 } \ 

require r : V . . . .(an >• 012) > (cm 02) 



These types are very similar; they may be read as follows. Both wrappers expect 
a function / which allows that r be enabled (r : Pre), i.e. one which either 
requires r to be enabled, or doesn’t care about its status. (Indeed, as in ML, 
the type of the actual argument may be more general than that of the formal.) 
They return a new function with identical domain and codomain (cm, a 2 ), which 
works regardless of r’s status ( enable r yields r : 72) or requires r to be enabled 
( require r yields r : Pre). The new function retains /’ s expectations about s 
(s : 71). / must not require any further privileges (9Abs), because it is invoked 
by p, which enjoys privileges r and s only. 

These polymorphic types are very expressive. Our main concern is that, even 
though the privilege s is not mentioned in the code of these wrappers, it does 
appear in their type. More generally, every privilege in A(p) may show up in 
the type of a function written on behalf of principal p , which may lead to very 
verbose types. An appropriate type abbreviation mechanism may be able to 
address this problem; this is left as a subject for future work. 



7.3 Advanced Examples 

We lack space to cover numerous more subtle features of the type systems; let 
us give only some brief comments. 
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In Sect. o our use of testpriv was easily seen to be correct, because the 
sensitive action kill(p) was performed within its lexical scope. Matters become 
more delicate when testpriv is used to yield a function (or, in Java, an object), 
whose security requirements depend on the test’s outcome, and which is later 
invoked outside its scope. Conditional constraints are then required to track 
the dependency and prove that the function invocation is safe. It is not clear 
whether this idiom is a critical one to support in practice, and the question may 
be answerable only through experiment. 

In Sect. o we pointed out that it is legal to pass enable r a function / which 
doesn’t care about the status of r, provided the type of / is polymorphic in r’s 
status, as in 



Vq.oq 



l r: 7 ; 0 } 

>• a 2 



If, on the other hand, it is monomorphic (because / is A-bound rather than 
let-bound), as in 

{rrEither ; {3} 

O i y O' 2 



then the application ( enable r f) becomes well-typed only if subtyping is available, 
i.e. if Pre is a subtype of Either. We expect this situation to be infrequent, 
although this remains to be confirmed. 



8 Discussion 

Extension to a Full-Featured Language. Many features of the Java language or 
environment are not addressed in this theoretical study. In particular, Java views 
privileges as first-class objects, making static typing problematic. In our model, 
privileges are identifiers, and expressions cannot compute privileges. In the case 
of Java, it is an open question whether a completely static mechanism can be 
devised. If not, it may be desirable to take a soft typing approach p. 

Related Work. The security-passing style translation described in Sect. El is 
monadic. Monadic type systems have been used to analyze the use of impure 
language features in otherwise pure languages HU- However, as deplored in PH, 
there is still “a need to create a new effect system for each new effect” . In other 
words, we apparently cannot readily re-use the work on monadic type systems in 
our setting. In fact, our work may be viewed as a systematic construction of an 
“effect” type system adapted to our particular effectful programming language. 

Several researchers have proposed ways of defining efficient, provably correct 
compilation schemes for languages whose security policy is expressed by a se- 
curity automaton. Walker P2| defines a source language, equipped with such a 
security policy, then shows how to compile it into a dependently-typed target 
language, whose type system, by encoding assertions about security states, guar- 
antees that no run-time violations will occur. Walker first builds the target type 
system, then defines a typed translation. On the opposite, our approach con- 
sists in first defining an untyped translation, then letting the source type system 
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arise from it. Thiemann’s approach to security automata m is conceptually 
much closer to ours: he also starts with an untyped security-passing translation, 
whose output he then feeds through a standard program specializer, in order to 
automatically obtain an optimizing translation. 

Our paper shares some motivations with these works; however, our aim was 
not only to gain performance by eliminating many dynamic checks, but also to 
define a programming discipline. This requires security types to be available not 
only at the level of compiled code, as in Walker’s work, but also in the source 
code itself. 



References 

[1] Alexander S. Aiken, Edward L. Wimmers, and T. K. Lakshman. Soft typing 
with conditional types. In Principles of Programming Languages, pages 163-173, 
January 1994. URL: http://http.cs.berkeley.edu/~aiken/ftp/popl94.ps 

[2] Li Gong. Java security architecture (JDK1.2). 

URL: http : //java. sun. com/products/ jdk/1 . 2/docs /guide/ security/ spec/ 
security-spec.doc.html, October 1998. 

[3] Martin Odersky, Martin Sulzmann, and Martin Wehr. Type inference with con- 
strained types. Theory and Practice of Object Systems, 5(l):35-55, 1999. URL: 
http : / /www. cs .mu. oz . au/~sulzmann/publications/tapos .ps. 

[4] Frangois Pottier. A 3-part type inference engine. In Gert Smolka, editor, Proceed- 
ings of the 2000 European Symposium on Programming (ESOP’OO), volume 1782 
of Lecture Notes in Computer Science, pages 320-335. Springer Verlag, March 
2000. URL: http://pauillac.inria.fr/ fpottier/publis/fpottier-esop-2000.ps.gz. 

[5] Frangois Pottier and Sylvain Conchon. Information flow inference for free. In Pro- 
ceedings of the the Fifth ACM SIGPLAN International Conference on Functional 
Programming (ICFP’00), pages 46-57, September 2000. 

URL: http://pauillac.inria.fr/ fpottier/publis/fpottier-conchon-icfpOO.ps.gz. 

[6] Didier Remy. Extending ML type system with a sorted equational theory. Techni- 
cal Report 1766, INRIA, Rocquencourt, BP 105, 78153 Le Chesnay Cedex, France, 
1992. URL: 

ftp://ftp.inria.fr/INRIA/Projects/cristal/Didier.Remy/eq-theory-on-types.ps.gz. 

[7] Didier Remy. Projective ML. In 1992 ACM Conference on Lisp and Functional 
Programming, pages 66-75, New- York, 1992. ACM Press. URL: 
ftp://ftp.inria.fr/INRIA/Projects/cristal/ Didier. Remy/lfp92.ps.gz. 

[8] Christian Skalka and Scott Smith. Static enforcement of security with types. In 
Proceedings of the the Fifth ACM SIGPLAN International Conference on Func- 
tional Programming (ICFP’00), pages 34-45, Montr al, Canada, September 2000. 
URL: http : //www . cs . jhu. edu/~ces/papers/secty_icfp2000 .ps . gz 

[9] Martin Sulzmann, Martin Muller, and Christoph Zenger. Hindley/Milner style 
type systems in constraint form. Research Report ACRC-99-009, University of 
South Australia, School of Computer and Information Science, July 1999. URL: 
http : / /www.ps .uni-sb . de/ "mmueller /paper s/hm- constraints .ps . gz. 

[10] Peter Thiemann. Enforcing security properties using type specialization. In David 
Sands, editor, Proceedings of the 2001 European Symposium on Programming 
(ESOP’01), Lecture Notes in Computer Science. Springer Verlag, April 2001. 



A Systematic Approach to Static Access Control 



45 



[11] Philip Wadler and Peter Thiemann. The marriage of effects and monads. Sub- 
mitted to ACM Transactions on Computational Logic. URL: 

http: / / cm. bell-labs. com/cm / cs /who / wadler / papers / effectstocl / effectstocl.ps. gz. 

[12] David Walker. A type system for expressive security policies. In Conference Record 
of POPL’OO: The 27th ACM SIGPLAN-SIGACT Symposium on Principles of 
Programming Languages, pages 254-267, Boston, Massachusetts, January 2000. 
URL: http : //www . cs . Cornell . edu/home/walker /papers/ sa-popl00_ps . gz. 

[13] Dan S. Wallach. A New Approach to Mobile Code Security. PhD thesis, Princeton 
University, January 1999. 

URL: http : //www . cs .princeton. edu/sip/pub/dwallach-dissertation.html 

[14] Andrew K. Wright and Matthias Felleisen. A syntactic approach to type sound- 
ness. Information and Computation, 115(l):38-94, November 1994. 

URL: http : //www . cs . rice . edu/CS/PLT/Publications/ic94-wf .ps .gz. 



Secure Information Flow and CPS 



Steve Zdancewic and Andrew C. Myers 

Cornell University, Ithaca NY 14853, USA 

{zdance , andru}@cs . Cornell . edu 



Abstract. Security-typed languages enforce secrecy or integrity policies 
by type-checking. This paper investigates continuation-passing style as 
a means of proving that such languages enforce non-interference and as 
a first step towards understanding their compilation. We present a low- 
level, secure calculus with higher-order, imperative features. Our type 
system makes novel use of ordered linear continuations. 



1 Introduction 

Language based mechanisms for enforcing secrecy or integrity policies are attrac- 
tive because, unlike ordinary access control, static information flow can enforce 
end-to-end policies. These policies require that data be protected despite being 
manipulated by programs with access to various covert channels. For exam- 
ple, such a policy might prohibit a personal finance program from transmitting 
credit card information over the Internet even though the program needs Inter- 
net access to download stock market reports. To prevent the finance program 
from illicitly transmitting the private information (perhaps cleverly encoded), 
the compiler checks that the information flows in the program are admissible. 

There has been much recent work on formulating Denning’s original lat- 
tice model of information-flow control f3j in terms of type systems for static 
program verification . The desired security property is 

non-interference 0, which states that high-security data is not observable by 
low-security computation. Nevertheless, secure information flow in the context 
of higher-order languages with imperative features is not well understood. 

This paper proposes the use of continuation-passing style (CPS) transla- 
tions |8|1 2128) as a means of ensuring non-interference in imperative, higher- 
order languages. There are two reasons for using CPS. First, CPS is a vehicle 
for proving a non-interference result, generalizing previous work by Smith and 
Volpano m ■ Second, CPS is useful for representing low-level programs prrcj . 
which opens up the possibility of verifying the security of compiler output via 
typed assembly language m or proof-carrying code m- 
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We observe that a naive approach to providing security types for an imper- 
ative CPS language yields a system that is too conservative: secure programs 
(in the non-interference sense) are rejected. To rectify this problem, we intro- 
duce ordered linear continuations , which allow information flow control in the 
CPS target language to be made more precise. The ordering property of linear 
continuations is crucial to the non-interference argument, which is the first such 
theorem for a higher-order, imperative language. 

As with previous non-interference results for call-by- value languages ircim 
the theorem holds only for programs that halt regardless of high-security data. 
Consequently, termination channels can arise, but they leak at most one bit per 
run on average, we consider them acceptable. There are other channels not cap- 
tured by this notion of non-interference: high-security data can alter the running 
time of the program or change its memory consumption. Non-interference holds 
despite these apparent information leaks because the language itself provides no 
means for observing these resources (for instance, access to the system clock). 
Recent work attempts to address such covert channels j3j. 

The next section shows why a naive type system for secure information flow 
is too restrictive for CPS and motivates the use of ordered linear continuations. 
Section 0 presents the target language, its operational semantics, and the novel 
features of its type system. The non-interference theorem is proved in Section 0 
and Section 0 demonstrates the viability of this language as a low-level calcu- 
lus by showing how to CPS translate a higher-order, imperative language. We 
conclude with some discussion and related work in Section 0 

2 CPS and Security 

Type systems for secrecy or integrity are concerned with tracking dependencies 
in a program [I]. One difficulty is implicit flows , which arise from the control 
flow of the program. Consider the code fragment A in Figure 0 There is an 
implicit flow between the value stored in x and the value stored in y, because 
examining the contents of y after the program has run gives information about 
the value in x. There is no information flow between x and z, however. This code 
is secure even when x and y are high-security variables and z is low-security. (In 
this paper, high security means “high secrecy” or “low integrity.” Dually, low 
security means “low secrecy” or “high integrity.”) 

Fragment B illustrates the problem with CPS translation. It shows the code 
from A after control transfer has been made explicit. The variable k is bound to 
the continuation of the if, and the jump is indicated by the application k (). 
Because the invocation of k has been lifted into the branches of the conditional, a 
naive type system for information flow will conservatively require that the body 
of k not write to low-security memory locations: The value of x would apparently 
be observable by low-security code. Program B is rejected because k writes to a 
low-security variable, z. 

However, this code is secure: There is no information flow between x and z in 
B because the continuation k is invoked in both branches. As example C shows, if 
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(A) if x then { y := 1; } else { y := 2; } 
z : = 3 ; halt ; 

(B) let k = (A() . z := 3; halt) in 

if x then { y := 1; k (); } else { y := 2; k () ; } 

(C) let k = (A() . z := 3; halt) in 

if x then { y := 1; k (}; } else { y:= 2; halt; } 

(D) letlin k = (A(). z := 3; halt) in 

if x then { y := 1; k (); } else { y:= 2; k () ; } 

(E) letlin kO = (A() . halt) in 

letlin kl = (Ak. z := 1; k (}) in 

letlin k2 = (Ak. z := 2; k (}) in 

if x then { letlin k = (A() . kl kO) in k2 k } 

else { letlin k = (A() . k2 kO) in kl k } 

Fig. 1. Examples of Information Flow in CPS 

k is not used in one of the branches, then information about x can be learned by 
observing z. Linear type systems can express exactly the constraint 

that k is used in both branches. By making k’s linearity explicit, the type system 
can use the additional information to recover the precision of the source program 
analysis. Fragment D illustrates our simple approach: In addition to a normal let 
construct, we include letlin for introducing linear continuations. The program 
D certifies as secure even when z is a low-security variable, whereas C does not. 

Although linearity allows for more precise reasoning about information flow, 
linearity alone is unsafe in the presence of first-class linear continuations. In 
example E, continuations kO, kl, and k2 are all linear, but there is an implicit 
flow from x to z because z lets us observe the order in which kl and k2 are 
invoked. It is thus necessary to regulate the ordering of linear continuations. 

It is simpler to make information flow analysis precise for the source language 
because the structure of the language limits control flow. For example, it is 
known that both branches of a conditional return to a common merge point. 
This knowledge can be exploited to obtain less conservative analysis of implicit 
flows, but the standard CPS transformation loses this information by unifying all 
forms of control to a single mechanism. In our approach, the target language still 
has a single underlying control transfer mechanism (examples B and D execute 
exactly the same code), but information flow can be analyzed with the same 
precision as in the source. 

3 The Secure CPS Calculus 

The target is a call-by-value, imperative language similar to those found in the 
work on Typed Assembly Language [itillSj . although its type system is inspired 
by previous language-based security research fTSBUim This section describes 
the secure CPS language, its operational behavior, and its static semantics. 
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Types 
l, pc £ £ 



Expressions 



Values and Primitive Operations 

bv ::= n | (> | L CT | A[pc ]f(x:o,y.n).e 
v ::= x | bvt 

Iv ::= (> | y | A(pc)(a;:<7,?/:/c).e 



a ::= re 



K ::= 1 | (a, k) 0 



t ::= int | 1 | a ref | [pc] (cr, k) —>■ 0 



e 



let x = prim, in e 
let x = ref J v in e 
set v := u in e 
letlin y = Iv in e 
let () = It) in e 
ifO v then e else e 
goto v v Iv 
lgoto Iv v Iv 
halt CT v 



prim ::= v \ v ® v | deref(u) 



Fig. 2. Syntax for the Secure CPS Language 



3.1 Syntax 

The syntax for the secure CPS language is given in Figure 0. Elements of the 
lattice of security labels, £, are ranged over by meta-variables t and pc. We 
reserve the meta-variable pc to suggest that the security label corresponds to 
information learned by observing the program counter. The C operator denotes 
the lattice ordering, with the join operation given by U, and least element _L. 

Types fall into two syntactic classes: security types, <r, and linear types, 
k. Security types are the types of ordinary values and consist of a base-type 
component, r, annotated with a security label, t. Base types consist of integers, 
unit, references, and continuations (written [pc] (cr, k) — > 0). Correspondingly, 
base values, bv, include integers, n, a unit, (}, type-annotated memory locations, 
L a , and continuations, A [p c\f(x:<j,y:n).e. All computation occurs over secure 
values, v, which are base values annotated with a security label. Variables, x, 
range over values. We adopt the notation label (ji) = t, and extend the join 
operation to security types: T(\J £' = r/eui')- 

An ordinary continuation A[p c\f(x:a,y.n). e is a piece of code (the expression 
e) that accepts a non-linear argument of type cr and a linear argument of type 
n. Continuations may recursively invoke themselves using the variable /. The 
notation [pc] indicates that this continuation may be called only from a context 
in which the program counter carries information of security at most pc. To 
avoid unsafe implicit flows, the body of the continuation may create effects only 
observable by principals able to read data with label pc. 

Linear values are either unit, variables, or linear continuations, which contain 
code expressions parameterized by non-linear and linear arguments just like 
ordinary continuations. Unlike ordinary continuations, linear continuations may 
not be recursiv(Q. but they may be invoked from any calling context; hence linear 
types do not require any pc annotation. The syntax (pc) serves to distinguish 

1 A linear continuation k may be discarded by a recursive ordinary continuation that 
loops infinitely, passing itself k. Precise terminology for our “linear” continuations 
would be “affine” to indicate that they may, in fact, never be invoked. 
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linear continuation values from non-linear ones. As for ordinary continuations, 
the label pc restricts the continuation’s effects. 

The primitive operations include binary arithmetic (©), dereference, and a 
means of copying secure values. Program expressions consist of a sequence of 
let bindings for primitive operations, reference creation, and imperative up- 
dates (via set). The letlin construct introduces a linear continuation, and the 
expression let () = Iv in e, necessary for type-checking but operationally a 
no-op, eliminates a linear unit before executing e. Straight-line code sequences 
are terminated by conditional statements, non-local transfers of control via goto 
(for ordinary continuations) or lgoto (for linear continuations), or halt. 

3.2 Operational Semantics 

The operational semantics (Figure 0) are given by a transition relation between 
machine configurations of the form ( M , pc, e). Memories, M, are finite partial 
maps from typed locations to closed values. The notation M[L a -s— v\ denotes 
the memory obtained from M by updating the location L a to contain the value v 
of type cr. A memory is well-formed if it is closed under the dereference operation 
and each value stored in the memory has the correct type. The notation e{v /x} 
indicates capture-avoiding substitution of value v for variable x in expression e. 

The label pc in a machine configuration represents the security level of infor- 
mation that could be learned by observing the location of the program counter. 
Instructions executed with a program-counter label of pc are restricted so that 
they update only to memory locations with labels more secure than pc. For 
example, [E3] shows that it is valid to store a value to a memory location of 
type a only if the security label of the data joined with the security labels of 
the program counter and the reference itself is lower than label (cr), the security 
clearance needed to read the data stored at that location. Rules [ E6 ] and [E 7} 
show how the program-counter label changes after branching on data of security 
level i. Observing which branch is taken reveals information about the condition 
variable, and so the program counter must have the higher security label pc U £. 

As shown in rules [P1]-[P3], computed values are stamped with the pc label. 
Checks like the one on [E3] prevent illegal information flows. The two let rules 
([El] and [Ef]) substitute the bound value in the rest of the program. 

Operationally, the rules for goto and lgoto are very similar — each causes 
control to be transferred to the target continuation. They differ in their treat- 
ment of the program-counter label, as seen in rules [ E8 ] and [E9]. Ordinary 
continuations require that the pc before the jump be bounded above by the label 
associated with the body of the continuation, preventing implicit flows. Linear 
continuations instead cause the program-counter label to be restored (potentially 
lowered) to that of the context in which they were declared. 

3.3 Static Semantics 

The type system for the secure CPS language enforces the linearity and ordering 
constraints on continuations and guarantees that security labels on values are re- 
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[PI] (M, pc, bve) JJ bviupc [P2] (M, pc, ni®n' t i) JJ (ra[©] n')tut.'upc 

M(L a ) = bv t , 

[PS] (M, pc, deref (Z4I)) JJ. bv eue > U pc 

(M, pc, prim ) JJ. v 

[El] ( M , pc, let x = prim in e) i — ¥ ( M , pc, e{v/x}) 

<U pc C label (cr) L CT 0 Dom(M) 

[E2] ( M , pc, let x = ref J, bve in e> i — ¥ {M[L a <— bveupc], pc, e{LJ, Upc /a:}) 

i LI P U pc C label (cr) L a 6 Dom(M) 

[E3] {. M , pc, set L( := in e) i — > {M[L a few^ur'upc]. pc, e) 

[E4] ( M , pc, letlin y = Iv in e) i — ¥ ( M , pc, e{Zv/j/}) 

[i?5] (M, pc, let () = (} in e) i — ¥ (M, pc, e) 

( M , pc, ifO Or then ei else e 2 ) i — > (M, pc LI £, ei) 

[E7] ( M , pc, if 0 nr then ei else e 2 ) i — ¥ ( M , pc U e 2 ) (n ^ 0) 

pc E pc' v = (\[pc'] f(x:a,y:K).e)i e' = e{v/ f}{bvt Upc /x}{lv/y} 

[E8] ( M , pc, goto (A[pc']/(a; : cr, y: n). e)r 6tr' Zv) 1 — > (M, pc' Ul, e!) 

[E9] ( M , pc, lgoto (X(pc') (x: a, y.K).e) bve Iv) i — > (M, pc', e{fetru P c/a;}{Zt/?/}} 
Fig. 3. Expression Evaluation 

spected. Together, these restrictions rule out illegal information flows and impose 
enough structure on the language for us to prove a non-interference property. 

As in other mixed linear-non-linear type systems EH, two separate type 
contexts are used. T is a finite partial map from non-linear variables to security 
types, whereas K is an ordered list (with concatenation denoted by mapping 
linear variables to their types. The order in which continuations appear in K 
defines the order in which they are invoked: Given K = •, ( y n : K n ), . . . , ( y \ : «i), 
the continuations will be executed in the order yi ■ ■ .y n - The context T admits 
the usual weakening and exchange rules (which we omit), but K does not. The 
two contexts are separated by || in the judgments to make them more distinct, 
and • denotes an empty context. 

Figures^andElshow the rules for type-checking. The judgment form T b v : cr 
says that ordinary value v has security type a in context T. Linear values may 
mention linear variables and so have judgments of the form T || K b Iv : k. 
Primitive operations may not contain linear variables, but the security of the 
value produced depends on the program-counter: T [pc] b prim : cr says that 
in context T where the program-counter label is bounded above by pc, prim 
computes a value of type a. Similarly, T || K [pc] b e means that expression e is 
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[TV1] 


r b ne : inR 




f,x£ Dom( T) 








a 1 = ([pc](cr, k) -4 0)e 


[ TV2 ] 


r b {)t : u 




r,f:a',x:cr || y.K [pc] h e 






[: TV 5 ] 


Lb (\[pc]f(x :a,y : k). e)e : a' 


[TVS] 


r h LJ \ a reR 












V h v : cr b<7<<7 / 


[TV4] 


— r(x) = a 

r b x : a W 


[: TV 6 ] 


Thv.a' 




pc' C pc b a' < 


a h k' < K 


b r < t' iV(! 


[54] b [pc] (a, k) — ¥ 0 < 


[pc 


-4 0 [52] b Tt < T e i 








x qL Dom(T), y ^ Dom( K) 


[TL1] 


r || . h <> : 1 




k! = (a, Hi) — ^ 0 








T ,x:a || y.K, K [pc] b e 


[ TL2 ] 


r || y : K b y : K 


[TL3] r 


|| K b A(pc)(a: -.a,y:K).e : k 



Fig. 4. Value and Linear Value Typing 

type-safe and contains no illegal information flows in the type context T || K, 
when the program-counter label is at most pc. In the latter two forms, pc is a 
conservative approximation to the information affecting the program counter. 

The rules for checking ordinary values, [TV1]-[TV6] shown in Figure El are, 
for the most part, standard. A value cannot contain free linear variables because 
discarding (or copying) it would break linearity. A continuation type contains 
the pc label used to check its body (rule [TV5]). The lattice ordering on security 
labels lifts to a subtyping relationship on values (rule [ S2 ] ) . Continuations exhibit 
the expected contravariance (rule [SI]). We omit the obvious reflexivity and 
transitivity rules. Reference types are invariant, as usual. 

Linear values are checked using rules [ TL1 ] [ TL3 ]. They may safely mention 
free linear variables, but the variables must not be discarded or reordered. Thus, 
unit checks only in the empty linear context (rule [TL1]), and a linear variable 
checks only when it is alone in the context (rule [TL2]). In a linear continuation 
(rule [TL3]), the linear argument, y , is the tail of the stack of continuations yet 
to be invoked. Intuitively, this judgment says that the continuation body e must 
invoke the continuations in K before jumping to y. 

The rules for primitive operations ([ TP1 ] [TPS] in Figure 0 require that 
the calculated value have security label at least as restrictive as the current pc, 
reflecting the “label stamping” behavior of the operational semantics. Values 
read through deref (rule [TP3]) pick up the label of the reference as well, which 
prevents illegal information flows due to aliasing. 

Rule [TE4] illustrates how the conservative bound on the security level of 
the program-counter is propagated: The label used to check the branches is 
the label before the test, pc, joined with the label on the data being tested, 
l. The rule for goto, [TE8], restricts the program-counter label of the calling 
context, pc, joined with the label on the continuation itself, l, to be less than 
the program-counter label under which the body was checked, pc'. This prevents 
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r b v : a pc C label (cr) 




rb»: intf F b v 1 : i nt£ pc C £ 


[TP1] 


F [pc] h v : a 


[TPS] 


F [pc] b»©»' : i nt£ 




T b v : a ref( pc C label(<7 LI l) 






[TP 3] 


T [pc] b deref (v) : cr LI t 








F [pc] b prim : a 
V,x:a || K [pc] b e 




r b v : a pcCfU label(cr) 
r,a;:cr reU || K [pc] b e 


[TE1] 


r || K [pc] b let x = prim in e 


[TE2] 


r || K [pc] b let x = ref ^ v in e 




r b v : cr refe T || I< [pc] b e 
r b v' : a pc LI l C label(<r) 




r b v : int« r || I< [pc U £] b a 


[ TE3 ] 


r || K [pc] b set v := v' in e 


[TE4] 


r || K [pc] b ifO v then ei else e 2 




T || K 2 b A(pc ')(x:a, y 
pc C pc' T | Ki ,y : 


:k). e! : (a, k) — » 0 
(cr, k) —¥ 0 [pc] b e 


[TE5] 


r || Ki,K 2 [pc] b letlin y = 


A(p c')(x:a,y: k). e' in e 




r b v : a pc C label(er) 




r || Ki f lv : 1 T || K 2 [pc] b e 


[TE6] 


r || • [pc] b halt CT v 


[TE7] 


F || Ki, K 2 [pc] b let () = Iv in e 




rbo: ([pc'] (a, ft) ->■ Q) t 
r b v' : a r || K b Iv : K 

pc LUC pc' pc C label(<r) 




r || K 2 b Iv : (cr, k) — » 0 
r b v : 0 F || Ki b Iv’ : k 

pc C label(cr) 


[TE8] 


r || K [pc] b goto v v' Iv 


[TE9] 


T || Ki,K 2 [pc] b lgoto Iv v Iv 1 



Fig. 5. Primitive Operation and Expression Typing 

implicit information flows from propagating into function bodies. Likewise, the 
values passed to a continuation (linear or not) must pick up the calling context’s 
pc (via the constraint pc C label (cr)) because they carry information about the 
context in which the continuation was invoked. 

The rule for halt, [ TE6 ], requires an empty linear context, indicating that 
the program consumes all linear continuations before stopping. The a annotating 
halt is the type of the final output of the program; its label should be constrained 
by the security clearance of the user of the program. 

The rules for letlin, [TE5], and lgoto, [TE9], manipulate the linear context 
to enforce the ordering property on continuations. For letlin, the linear context 
is split into Ki and K 2 . The body e is checked under the assumption that the 
new continuation, y, is invoked before any continuation in Ki . Because y invokes 
the continuations in K 2 before its linear argument (as described above for rule 
[' TL3 ]), the ordering K 1; K 2 in subsequent computation will be respected. The 
rule for lgoto works similarly. 

Linear continuations capture the pc (or a more restrictive label) of the con- 
text in which they are introduced, as shown in rule [ TE5 ). Unlike the rule for 
goto, the rule for lgoto does not constrain the pc, because the linear continu- 
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ation restores the program-counter label to the one it captured. Because linear 
continuations capture the pc of their introduction context, we make the mild 
assumption that initial programs introduce all linear continuation values (not 
variables) via letlin. During execution this constraint is not required, and pro- 
grams in the image of the translation satisfy this property. 

This type system is sound with respect to the operational semantics ESI- 
The proof is, for the most part, standard, following in the style of Wright and 
Felleisen ESI- We simply state the lemmas necessary for the discussion of the 
non-interference result of the next section. 

Lemma 1 (Subject Reduction). If • || K [pc] b e and M is a well-formed 
memory such that Loc(e) C Dom(M) and (M, pc, e) i — > (M' , pc', e'), then 
• || K [pc'] b e' and M' is a well-formed memory such that Loc{e ') C Dom(M'). 



Lemma 2 (Progress). If • || • [pc] b e and Mis well-formed and Loc(e) C 
Dom(M), then either e is of the form halt CT v or there exist M', pc', and e! 
such that ( M , pc, e) i — > (M', pc', e!) 

Note that Subject Reduction holds for terms containing free occurrences of 
linear variables. This fact is important for proving that the ordering on linear 
continuations is respected. The Progress lemma (and hence Soundness) applies 
only to closed programs, as usual. 

4 Non-interference 

This section proves a non-interference result for the secure CPS language, gen- 
eralizing Smith and Volpano’s preservation-style argument m ■ A technical re- 
port m gives a detailed account of our approach in a more expressive language. 

Informally, the non-interference result shows that low-security computations 
are not able to observe high-security data. Here, “low-security” refers to the set 
of security labels C £, where £ is an arbitrary point in C , and “high-security” 
refers to labels % £. The proof shows that high-security data and computation 
can be arbitrarily changed without affecting the value of any computed low- 
security result. Furthermore, memory locations visible to low-security observers 
(locations storing data labeled C Cf) are also unaffected by high-security values. 

Non-interference reduces to showing that two programs are equivalent from 
the low-security perspective. Given a program e\ that operates on high- and 
low-security data, it suffices to show that ei is low-equivalent to the program e^ 
that differs from ei in its high-security computations. 

How do we show that ei and ei behave the same from the low-security point 
of view? If pc C <C, meaning that ei and ei may perform actions visible to low 
observers, they necessarily must perform the same computation on low-security 
values. Yet ei and ei may differ in their behavior on high-security data and still 
be equivalent from the low perspective. To show their equivalence, we should 
find substitutions 71 and 72 containing the relevant high-security data such that 
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e = 71(e) and e 2 = 72(e)— both ei and e2 look the same after factoring out the 
high-security data. 

On the other hand, when pc (2 (, no matter what ei and e2 do their ac- 
tions should not be visible from the low point of view; their computations are 
irrelevant. The operational semantics guarantee that the program-counter label 
is monotonically increasing except when a linear continuation is invoked. If ei 
invokes a linear continuation causing pc to fall below (, e2 must follow suit; 
otherwise the low-security observer can distinguish them. The ordering on linear 
continuations forces e2 to invoke the same low-security continuation as ei. 

The crucial invariant maintained by well-typed programs is that it is possible 
to factor out (via substitutions) the relevant high-security values and those linear 
continuations that reset the program-counter label to be C (. 

Definition 1 (Substitutions). For context T, let 7 \= T mean that 7 is a finite 
map from variables to closed values such that Dom("f) = Dom(T) and for every 
x £ Dom (7) it is the case that • b 7(2:) : T(a;). 

For linear context K, write T b k \= K to indicate that k is a finite map of 
variables to linear values (with free variables from T ) with the same domain as 
K and such that for every y £ Dom(k) we have T || • b k(y) : K (y). 

Substitution application, written 7(e), indicates the capture-avoiding substi- 
tution of the value 7(2:) for free occurrences of x in e, for each x in the domain 
of 7 (fc(e) is defined similarly). 

Linear continuations that set the pc label % ( may appear in low-equivalent 
programs, because, from the low-security point of view, they are not relevant. 

Definition 2 (letlin Invariant). A term satisfies the let 1 in invariant if 
every linear continuation expression A(pc)(x: cr, y : n). e appearing in the term is 
either in the binding position of a letlin or satisfies pc (2 (. 

If substitution k contains only low-security linear continuations and k{e) is a 
closed term such that e satisfies the letlin invariant, then all the low-security 
continuations not letlin-bouncl in e must be obtained from k. This invariant 
ensures that k factors out all of the relevant continuations from k{e). 

Extending these ideas to values, memories, and machine configurations we 
obtain the definitions below: 

Definition 3 ((-Equivalence). 

r b 71 « c 72 If 71, 72 |= T and for every x £ Dom(T) it is the case that 

label(7j(:r)) % ( and 7 i(x) satisfies the letlin invariant. 

T || K b fci « c k 2 If T b k\, k 2 |= K and for every y £ Dom( K) it is the case 
that k\(y) = a k 2 (y) = X(pc) (x : cr, y' :n).e such that pc C ( 
and e satisfies the letlin invariant. 

vi V 2 : cr If there exist T, 71, and 72 plus terms = a v' 2 such that 

T b 71 72, and T b v[ : a and Vi = 7,(i() and each v\ 

satisfies the letlin invariant. 
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M\ M2 If for all L a G Dom(Mi) U Dom(M2) z/label(<r) C f/ien 

L a G Dom(Mi) n Dom(M 2 ) and Mi(L a ) « c M 2 (L CT ) : ct. 

Definition 4 (Non-Interference Invariant). 77ie non-interference invariant 
is a predicate on machine configurations, written r || K b (Mi, pc l5 ei) 
(Mi, pc 2 , e 2 ) t/iat holds if the following conditions are all met: 

(i) There exist substitutions 71,72, ki,k 2 and terms e\ and e' 2 such 
that ei = 7 i(fci(e , i)) and e 2 = 7 2 (/c 2 (e 2 )). 

(ii) Either (a) pci = pc 2 C £ and e\ = a e 2 or (&) T || K [pq] b e' x 
and r || K [pc 2 ] b e 2 and pq % 

(iii) r h 71 7 2 and T || K b k\ fc 2 

(iv) Loc(ei) C Dom(Mi) and Loc(e 2 ) C Dom(M 2 ) and Mi M 2 . 

(v) Bof/i and e 2 satisfy the letlin invariant. 

Our proof is a preservation argument showing that the Non-Interference In- 
variant holds after each transition. When the pc is low, equivalent configurations 
execute in lock step (modulo high-security data). After the program branches 
on lrigh-security information (or jumps to a high-security continuation), the two 
programs may temporarily get out of sync, but during that time they may affect 
only high-security data. If the program counter drops low again (via a linear 
continuation), both computations return to lock-step execution. 

We first show that ((-equivalent configuration evaluate in lock step as long as 
the program counter has low security. 

Lemma 3 (Low-pc Step). Suppose T || K b (Mi, pci, ei) (M 2 , pc 2 , e 2 ), 
pc : C ( and pc 2 C ((• If (Mi, pc 1 , ei) 1 — >■ (M(, pcj, e'l), then (M 2 , pc 2 , e 2 ) 1 — >■ 
(M 2 , pc 2 , e 2 ) and there exist D and K' such that D || K' b (M[, pc(, e'l) 
(M' 2 , pc' 2 , e 2 ). 

Proof. (Sketch) We omit the details due to space constraints. Reason by cases on 
the security of the value used in the transition — if it’s label is C <(, a-equivalence 
implies both programs behave identically, otherwise, we extend the substitutions 
corresponding to F’ to contain the differing high-security data. □ 

Next, we prove that linear continuations do indeed get called in the order 
described by the linear context. 

Lemma 4 (Linear Continuation Ordering). Assume K = y n : n n , . . . ,yi : 

Ki, each Hi is a linear continuation type, and • || K [pc] be. If • \~ k \= K, then 
in the evaluation starting from any well-formed configuration ( M , pc, k(e)), the 
continuation k(yi) will be invoked before any other k(yi). 

Proof. The operational semantics and Subject Reduction are valid for open 
terms. Progress, however, does not hold for open terms. Evaluate the open term 
e in the configuration (M, pc, e). If the computation diverges, none of the yfs 
ever reach an active position, and hence are not invoked. Otherwise, the com- 
putation must get stuck (it can’t halt because Subject Reduction implies that 
all configurations are well-typed; the halt expression requires an empty linear 
context). The stuck term must be of the form lgoto yi v Iv, and because it is 
well-typed, rule [TE9] implies that yi = yi- □ 
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We use the ordering lemma to prove that equivalent high-security configura- 
tions eventually return to equivalent low-security configurations. 

Lemma 5 (High-pc Step). If T || K h (Mi, pc 1; ei) (M2, pc 2 , e 2 ) and 
P c ,; % C> then (Mi, pc l5 ei) 1 — > (M(, pc;, e'f) implies that either e 2 diverges or 
(M 2 , pc 2 , e 2 ) 1 — >* (M 2 , pc 2 , e 2 ) and there exist T' and K' such that T' || K 7 h 
(M(, pc;, e'i) « c (M;, pc' 2 , e 2 ). 

Proof. (Sketch) By cases on the transition step of the first configuration. Because 
pci % C and all rules except [E9] increase the program-counter label, we may 
choose zero steps for e 2 and still show that is preserved. Condition (ii) holds 
via part(b). The other invariants follow because all values computed and memory 
locations written to must have labels higher than pc x (and hence % £). Thus, the 
only memory locations affected are higlr-security: M[ R7 M 2 = M 2 . Similarly, 
[ TE5 } forces linear continuations introduced by ei to have pc (7 £• Substituting 
them in ei maintains clause (vi) of the invariant. 

Now consider the case for [E9]. Let ei = 7i(fci(e , 1 / )), then e" = lgoto Iv v\ Iv 1 
for some Iv. If Iv is not a variable, clause (vi) ensures that the program counter in 
/ids body is % £. Pick 0 steps for the second configuration as above. Otherwise, 
if Iv is a variable, y, then [TE9] guarantees that K = K ' ,y.K. By assumption, 
k\ (y) = \{pc)(x:<j,y':n').e, where pc C (. Assume e 2 does not diverge. By the 
ordering lemma, (M 2 , pc 2 , e 2 ) 1 — >* {M 2l pc' 2 , lgoto k 2 (y) v 2 lv 2 ). Simple in- 
duction on the length of this transition sequence shows that M 2 M 2 , because 
the program counter may not become C £. Thus, M( = M\ M 2 M 2 . By 
invariant (iii) , k 2 {y) = a k\{y). Furthermore, [ TE9 } requires that label (cr) (7 
Let T' = T,a::cr, = 71 { x 71 (ui) U pcj, i 2 = 72(2: 7 2 (u 2 ) U pc 2 }; take 

k[ and k ' 2 to be the restrictions of k\ and k 2 to the domain of K', and choose 
e\ = Yi{k[(e)) and e 2 = V 2 (k 2 (e)). All of the necessary conditions are satisfied 
as is easily verified via the operational semantics. □ 

Finally, we use the above lemmas to prove non-interference. Assume a pro- 
gram that computes a low-security value has access to lrigh-security data. Arbi- 
trarily changing the high-security data does not affect the program’s result. 

First, some convenient notation for the initial continuation: Let stop(re) : 
Kstop = X(±)( x :T£,y:l). let () = y in halt 1- * x where n stop = (n,l) 0 . 

Theorem 1 (Non-interference). Suppose x : a || y : K s t op [T] b e for some 
initial program e. Further suppose that label(cr) % C, and • h V\,v 2 : cr. Then 

(0, _L, e{v\ / x}{stop(\nt(f) / y}) 1 — (Mi, C, halt 11111 : mf) 

and 

(0, T, e{v 2 /x}{stop(\nt c )/y}) 1 — (M 2 , C, halt mt c m l2 ) 
implies that Mi «£ M 2 and n = m. 

Proof. It is easy to verify that 

x-.ct || y: K s top b (0, -L, e{v\ / x}{stop(\nX.(f) / y}) (0, _L, e{v 2 /x}{stop(\n\. c )/y}) 
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by letting 71 = {a; 1 — > 17}, 72 = {a: 1 — > V2}, and k\ = k2 = {y > stop(int^)}. 
Induction on the length of the first expression’s evaluation sequence, using the 
Low- and High- pc Step lemmas plus the fact that the second evaluation sequence 
terminates implies that T || K b (Mi, (, halt' ntf n 4) (M2, (, halt' n *< me 2 ). 

Clause (iv) of the Non-interference Invariant implies that M\ M2- Soundness 
implies that fi C ( and £2 E C- This means, because of clause (iii), that neither 
n nor ni { 2 are in the range of 7'. Thus, the integers present in the halt ex- 
pressions do not arise from substitution. Because ( E C, clause (ii) implies that 
halt m ^ c ri £ 1 = a halt m *k me 2 , from which we obtain n = m as desired. □ 

5 Translation 

This section presents a CPS translation for a secure, imperative, higher-order 
language that includes only the features essential to demonstrating the transla- 
tion. Its type system is adapted from the SLam calculus m to follow our “label 
stamping” operational semantics. The judgment T b pc e : s shows that expres- 
sion e has source type s under type context T, assuming the program-counter 
label is bounded above by pc. 

Source types are similar to those of the target, except that instead of contin- 
uations there are functions. Function types are labeled with their latent effect , 
a lower bound on the security level of memory locations that will be written to 
by that function. The type translation, following previous work on typed CPS 
conversion is given in terms of three mutually recursive functions: (— )*, for 
base types, (— ) + for security types, and (— )“ to linear continuation types: 

int* = int (s ref)* = s + ref (si — S2 )* = [£](s+, s^) — » 0 
4 = (t*) e s~ = (s + , 1) — >■ 0 

Figure El shows the term translation as a type-directed map from source typ- 
ing derivations to target terms. For simplicity, we present an un-optimizing CPS 
translation, although we expect that first-class linear continuations will support 
more sophisticated translations, such as tail-call optimization 0. To obtain the 
full translation of a closed term e of type s, we use the initial continuation from 
Section^ letlin stop = stop(s + ) in [0 \~t e : sjstop. 

The basic lemma for establishing correctness of the translation is proved by 
induction on the typing derivation of the source term. This result also shows 
that the CPS language is at least as precise as the source. 

Lemma 6 (Type Translation). T \~t e : s => T+ || y:s [£] h [r e : s]y. 

6 Related Work 

The constraints imposed by linearity can be seen as a form of resource manage- 
ment in this case limiting the set of possible future computations. Linear 
continuations have been studied in terms of their category theoretic seman- 
tics HH and also as a computational interpretation of classical logic |5j. Polakow 
and Pfenning have investigated the connections between ordered linear-logic, 
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lT,x:s'\- pc x : s' U pc]y => lgoto y x () 



T,f:s,x:si hpc' e : s 2 
r h pc (yf{x : Si). e)r : s U pc 




f lg°t° V Wpc']f(x:sf,y' :s 2 ). 

\ [r,/:s,a::si hpc* e : s 2 ]y')* 0 



T h pc e : s 
T h pc e' : si 
t C pc' n label(si) 

r hpc (e e') : s 2 



3 / =>■ 



letlin fci = A(pc}(/ : s + , y\ : 1 ). 

let () = i/I in 

letlin fc 2 =A(pc)(x:Si ,i/ 2 :l). 

let (}= j/2 in 
goto f x y 
in [r h P c e' : si]fc 2 
in |r hpc e : s]fci 



r hpc e : int£ 

T hpc' ei : s' 
pc' 

F hpc ifO e then 
ei else e 2 : s 



letlin fci = A(pc)(o::intt,3/i : 1 ). 

let () = i/i in 
if 0 x then [F h pc ' ei : s'\y 
else [r h pc / e 2 : s'] 3/ 

in [r hpc e : intcjfci 



T h pc e : s' refr 
F h pc e' : s' 
i C label(s') 

r hpc e := e' : s' 



3 / => 



letlin fci = A(pc)(a:l:s , ref , t/r : 1) . 
let () = i/i in 
letlin fc 2 =A(pc)(a; 2 :s't 3/ 2 : 1 ). 
let () = 3/ 2 in 
set X\ := X2 in 
lgoto y X2 {) 
in [r h pc e' : s']fc 2 
in [F hpc e : s' refjfci 



Fig. 6. CPS Translation (Here s = (s i — s 2 )r, and the fchs and y^s are fresh.) 

stack-based abstract machines, and CPS m- Linearity also plays a role in se- 
curity types for process calculi such as the 7r-calculus HH. Because the usual 
translation of the A-calculus into the 7r-calculus can be seen as a form of CPS 
translation, it might be enlightening to investigate the connections between se- 
curity in process calculi and low-level code. 

CPS translation has been studied in the context of program analysis P33E3I- 
Sabry and Felleisen observed that increased precision in some CPS data flow 
analyses is due to duplication of analysis along different execution paths [Bit]. 
They also note that some analyses “confuse continuations” when applied to 
CPS programs. Our type system distinguishes linear from non-linear continu- 
ations to avoid confusing “calls” with “returns.” More recently, Damian and 
Danvy showed that CPS translation can improve binding-time analysis in the 
A-calculus suggesting that the connection between binding-time analysis and 
security [T] warrants more investigation. 

Linear continuations appear to be a higher-order analog to post-dominators 
in a control-flow graph. Algorithms for determining post-dominators (see Much- 
nick’s text ESI) might yield inference techniques for linear continuation types. 
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Conversely, linear continuations might yield a type-theoretic basis for correctness 
proofs of optimizations based on post-dominators. 

Understanding secure information flow in low-level programs is essential to 
providing secrecy of private data. We have shown that explicit ordering of con- 
tinuations can improve the precision of security types. Ordered linear continu- 
ations constrain the uses of continuations so that implicit flows of information 
can be controlled more accurately. These constraints also make possible our non- 
interference proof, the first of its kind for a higher-order, imperative language. 

Many thanks to James Cheney, Dan Grossman, Frangois Pottier, Stephanie 
Weirich, and Lantian Zheng for their comments on drafts of this paper. Thanks 
also to Jon Riecke for many interesting discussions about the SLam calculus. 
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Abstract. Type specialization can serve as a powerful tool in enforcing 
safety properties on foreign code. Using the specification of a monitoring 
interpreter, polyvariant type specialization can produce compiled code 
that is guaranteed to obey a specified safety policy. It propagates a secu- 
rity state at compile-time and generates code for each different security 
state. The resulting code contains virtually no run-time operations on 
the security state, at the price of some code duplication. A novel ex- 
tension of type specialization by intersection types limits the amount of 
code duplication considerably, thus making the approach practical. 



A few years back, mobile code was merely an exciting research subject. Mean- 
while, the situation has changed dramatically and mobile code is about to invade 
our everyday lives. Many applications load parts of their code — or even third- 
party extension modules — from the network and run it on the local computer. 
Web browsers are the most prominent of these applications, but many others 
(e.g., mobile agents) are gaining importance quickly. 

The advent of these applications and related incidents has brought an in- 
creasing awareness of the problems involved in executing foreign and potentially 
hostile programs. Clearly, it should be guaranteed that foreign code does not 
compromise the hosting computer, by crashing the computer (data integrity), 
by accessing/modifying data that it is not supposed to access (memory integrity) 
or -more generally — by using resources that it is not supposed to use. A gen- 
erally accepted way of giving this guarantee is to execute the code in a sand 
box. Conceptually, a sand box performs monitored execution. It tracks the exe- 
cution of foreign code and stops it if it attempts an illegal sequence of actions. 
A property that can be enforced in this way is called a safety property. 

Such sand box environments have been conceived and implemented with 
widely different degrees of sophistication. The obvious approach to such a sand 
box is to perform monitoring by interpreting the code. However, while the ap- 
proach is highly flexible it involves a large interpretation overhead. Another 
approach, taken by the JDK pa, is to equip strategic functions in a library with 
calls to a security manager. A user-provided instantiation of the security man- 
ager is then responsible to keep track of the actions and to prevent unwanted 
actions. The latter approach is less flexible, but more efficient. Java solves the 
problem of data and memory integrity statically by subjecting all programs to 
a bytecode verification process [ESI- 

D. Sands (Ed.): ESOP 2001, LNCS 2028, pp. 02-1771 2001. 

(c) Springer- Verlag Berlin Heidelberg 2001 
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Related Work 

The Omniware approach (E3IDD09 guarantees memory integrity by imposing a 
simple program transformation on programs in assembly language. The trans- 
formation confines a foreign module to its own private data and code segment. 
The approach is very efficient, but of limited expressiveness. 

Schneider eh shows that all and only safety properties can be decided by 
keeping track of the execution history. The history is abstracted into a (not 
necessarily finite) state automaton. The SASI project implemented this idea f I Yj 
for x86-assembly language and for JVM bytecode. Both allow for a separate 
specification of a state automaton and rely on an ad-hoc code transformation to 
integrate the propagation of the state with the execution of the program. 

Evans and Twyman [Bj have constructed an impressive system that takes a 
specification of a safety policy and generates a transformed version of the Java 
run-time classes. Any program that uses the transformed classes is guaranteed 
to obey the specified safety policy. 

Necula and Lee E1E3E3E1I have developed a framework in which com- 
piled machine programs can be combined with an encoding of a proof that the 
program obeys certain properties (for example, a safety policy). The resulting 
proof-carrying code is sent to a remote machine, which can check the proof lo- 
cally against the code, to make sure that it obeys the safety policy. This has 
been pursued further by Appel and others (201 Ej. 

Kozen m has developed a very light-weight version of proof-carrying code. 
He has built a compiler that includes hints to the structure of the compiled pro- 
gram in the code. A receiver of such instrumented code can verify the structural 
hints and thus obtain confidence that the program preserves memory integrity. 

Typed assembly language (TAL) [2| provides another avenue to generating 
high-level invariants for low-level code. Using TAL can guarantee type safety 
and memory integrity. TAL programs include extensive type annotations that 
enable the receiver to perform type checking effectively. 

Wallach and Felten EH coined the term security-passing style for a trans- 
formation that makes explicit the systematic extension of functions by an extra 
parameter encoding a security property. This idea has been pursued by a number 
of works, including the present one. 

Colcombet and Fradet [-Jj propose to transform code received from a foreign 
principal, guided by a safety policy. The transformed code propagates a run-time 
encoding of a security state which is checked at run-time to avoid illegal actions. 

Walker BHI presents a sophisticated type system that can encode the pass- 
ing of the security state on the type-level. The type system enables powerful 
optimizations. However, a separate transformation system must be implemented 
and lemmas about the security policy must be proven separately and fed into 
the system to enable optimizing transformations. 

Pottier and others m use a transformation to security-passing style as a 
starting point to generate a security-aware type system from a standard type 
system. They do not consider the implementation of the transformation. 

Implementing program transformations by program specialization has been 
proposed by Turchin and Gluck and put into practice by Gliick, Jprgensen, 

and others fTTlllDil.'iJl . 
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Syntax 

Exp B e ::= v | (if e e e) | 0(e . . . e) | e@(e . . . e) 

Value B v ::= x \ a | fix x(x . . . x)e 

evaluation contexts C ::= (if [ ] e e) | 0(u. . .[ ] e. . .) | [ ]@(e. . .e) | v@(v . . .[ ] e. . .) 

security states a G E 

base-type constants a G Base 

primitive operators 0 G Op 

types r ::= BaseType | (t, . . . , r) — > r 

Operational semantics 

a, (if true ei e 2 ) -Ba,e 1 
a, (if false ei 62 )— > cr, e 2 

a, 0(ai . . . a„) — > <5(0)(cr, ai . . . a n ), v if v = [0](ai, . . . , a„) is defined 

a, (fix *o(a;i . . . * n )e)@(ui ...v n )->cr, e[xo fix 10 ( 11 . . . x n )e, Xi v t ] 

If ct, e — > o', e' then o, C[e] — > o', C[e']. 

Fig. 1. The source language 



Contributions. The present work demonstrates that previous ad-hoc ap- 
proaches to enforcing safety properties by program transformation can be ex- 
pressed uniformly using partial evaluation. This simplifies their theoretical de- 
velopment and their implementation considerably since partial evaluation tech- 
nology is reused. 

After introducing the source language, security automata, and type special- 
ization, Section Qgives a naive implementation of monitored execution using an 
instrumented interpreter for a simply-typed call- by- value lambda calculus. 

In Section 0 we define a translation into a two-level lambda calculus. Type 
specialization DEI of the resulting two-level terms can remove (in certain cases) 
all run-time operations on the security state. Specialization creates variants of 
user code tailored to particular security states. They must be drawn from a finite 
set for our approach to work. 

In Section^ we introduce a novel extension of type specialization by intersec- 
tion types and subtyping. It avoids unnecessary code duplication, thus making 
our approach practical. Our prototype implementation automatically performs 
all example optimizations from Walker’s paper m- 

Technical results are the correctness proofs of the translation and the non- 
standard compilation performed by type specialization. They guarantee the 
safety of the translated and the compiled code. We have proved correct our ex- 
tension of type specialization, which amounts to proving subject reduction m- 

1 Prerequisites 

The source language, is a simply-typed call-by-value lambda calculus with 
constants, conditionals, and primitive operations on base types (see Fig. 0. 
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Each primitive operation, 0, can change the current security state. The value 
of fix xq{x\ . . . x n )e is a recursively defined function. Write A(a;i . . . x n )e if ap 
does not appear in e, and let x = e\ in e-i for (A(x)e 2 )@(ei). The typing rules 
defining the judgement Their are standard. 

Each primitive operation, 0 : BaseType™ — ► BaseType, comes with a partial 
semantic function [0] £ BaseType™ BaseType and a total state transition 
function, S : Op — ► £ x BaseType™ — > S, which models the change of the 
(security-) state on application of the operation. The semantics of the language 
is given in structural operational style. It maps a pair of a (security-) state, a, 
and a closed term to a new state and closed term. 

Each reduction sequence op> e o — > oi,ei ,— > gives rise to a potentially 
infinite sequence er = (op, or, . . .) of states (a trace). Write (To, eo j. o' ,v if there 
is a finite sequence of reductions, (To, eo —> <Ti, ei cr', v. 

Eta- value conversion is the reflexive, transitive, symmetric, and compatible 
closure of eta-value reduction: fix xq(xi, . . . , x„)u@(xi, . . . , x n ) —> vv v where 
xo, x \, . . . , x n are distinct variables not occurring free in v. 

A security automaton, is a tuple S = (£, Op , Value, 5, ao, bad) HI where 

— S is a countable set of states; 

— Op is a finite set of operation symbols; 

— Value is a countable set of values; 

— S : Op — > £ x Value* — > £ is a total function with 5(0)(bad, X\ . . . x n ) = bad 
(state transition function); 

— (To £ S is the initial state; and 

— bad £ S is the sink state with op yf bad. 

A safety policy is a set of finite and infinite traces that obeys certain restric- 
tions m A reduction sequence is acceptable if its associated trace is contained 
in the policy. Schneider HP has shown that all safety policies can be modeled 
by a security automaton. 

A closed term eo is safe with respect to S and some op £ £ \ { bad} if either 
there exist a’ £ E and v £ Value such that op,eo a',v and a' bad or the 
trace of op, eo is infinite. It is safe with respect to S if it is safe with respect to 
the initial state (To- 

A typical example is the policy that no network send operation happens 
after a read operation from a local file. The transition functions are the identity 
functions for all primitive operations except send and read. 



E = { before-read, after-read, bad} op = before-read 



<J 


<5(read)((j, file) 


(5(send)((r, data) 


<5(0)(ct, ...y n ) 


before-read 

after-read 

bad 


after-read 

after-read 

bad 


before-read 

bad 

bad 


before-read 

after-read 

bad 



The program (. A(x)read(/ife))@(send(data )) is safe (with respect to op) due 
to the trace ( before-read , before-read, after-read). It is not safe with respect to 
after-read: the corresponding trace is ( after-read , bad, bad). 

The program (A(a;)send((iata))@(read(/iZe)) is not safe with respect to any 
state: it generates the unacceptable traces ( before-read , after-read, bad) and 
( after-read , after-read , bad). 
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Type specialization. m transforms a source expression into a specialized 
expression and its specialized type. The type contains all the compile-time in- 
formation. If there is no run-time information left then the specialized expression 
becomes trivial, indicated by •, and can be discarded. 

In contrast, traditional partial evaluation techniques rely on non- 
standard interpretation or evaluation of a source program to perform as many 
operations on compile-time data as possible. They propagate compile-time data 
using compile-time values. Once a traditional specializer generates a special- 
ized expression, it loses all further information about it. This leads to the well- 
formedness restriction in binding-time analysis: if a function is classified as a 
run-time value, then so are its arguments and results. 

Since type specialization relies on type inference, there is no well-formedness 
restriction: compile-time and run-time data may be arbitrarily mixed. 

Figure 0 defines type specialization as a judgement rhe^e':r', that is, 
in typing context r the two-level term e specializes to specialized term e' with 
specialized type r'. In a two-level term, constants are always compile-time values, 
variables may be bound to compile-time or run-time values, lift converts a 
compile-time constant into a run-time constant, and poly and spec control 
polyvariance (see below). The operation ei+e 2 is an example primitive operation. 
For simplicity, we formalize only single-argument functions. 

Here is an example specialization of the term (Ax. lift x)@4: 

x x' : £{4} 5'{4} 

x ^ x' : 5'{4} b lift x 4 : Int 
0 b Ax. lift x Xx'A : 5{4} — > Int 0 b 4 • : S'{4} 

0 b (Ax. lift x)@4^ (Ax'.4)@» : Int 

The typing expresses the compile-time value 4 as a singleton type, 5'{4}. 

There are two significant changes with respect to Hughes’s presentation 1121 - 
First, Hughes’s two-level terms obey a simple type discipline. It ensures that 
the specializer never confuses compile-time and run-time values. However, it 
does not guarantee that the two-level term specializes successfully. Moreover, 
the specializer discovers errors of this kind anyway while inferring specialized 
types. Therefore, we have dropped this set of typing rules. 

Second, Hughes’s presentation hardwires the processing of singleton types 
into the rule for compile-time addition. Instead, we have formalized compile- 
time addition through conversion rules for singleton types. This choice simplifies 
the specification of extensions considerably, as demonstrated in Sec.0 

For brevity, our formalization does not include compile-time functions, which 
are expanded at compile-time before their specialized type is inferred. Their 
addition is exactly as in Hughes’s work BE1 and is orthogonal to the problems 
discussed in the present paper. 

The poly and spec constructs p2j introduce and eliminate polyvariant val- 
ues. A poly variant value is a set of specialized terms indexed by their specialized 
types. The type specializer employs a numeric encoding of the index in its out- 
put. It implements the rules using backtracking. 
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Syntax of two-level language 



Terms 



e ::= x \ n | e+e | if e then e else e | fix x(x)e \ e@e \ poly e | 
lift e | e+e | if e then e else e | fix x{x)e | e@e | spec e 
Specialized terms e' ::= • | x \ n \ e'+e' | if e' then e' else e! \ 
e'@e' | fix x(x)e' | (e', . . . , e') | 7 ri(e') 

Specialized types t' ::= S{n} \ Int \ t' — > r' \ t'+t' \ t' x ... x t' 

Typing contexts F ::= 0 | r, x e! : t' 



Equality on specialized types 

iii 

, , T 1 =T 2 t 2 



t 3 



T\ = r 2 



Tl = T 3 

/ / 
T3 = T 4 



Tl = T 2 
/ / 
f 2 = Tl 



Tl =T 2 t 3 = t 4 



Tl 



T 3 = T 2 



■ t 4 



Ti+t 3 = r 2 +r 4 

Inference rules of type specialization 
F, x e' : t' , F' h 1 m e' : t 



S'{ni}+<S'{n 2 } = 5{ni + n 2 } 



T h n • : S{n} 



fhe~>e' : S'{n} 



E h er ei : t[ 

r\~ e 2 e 2 : r 2 



7 1 h lift e n : Int 
r h ei e'i : 7nt 
f h e 2 ej : 7nt 



T I- ei+e 2 • : t(+t 2 
7 h eo ej : /S’ {0} T b ei e) : t' 
F h if eo then ei else e 2 ei : t’ 



T h ei+e 2 ei+ei : Int 
7h e 0 -+ ei, : S{1} F \- e 2 ^ e' 2 : F 
F h if eo then ei else e 2 e 2 : r 



F h eo e'o : Int F h ei ei : r' F h e 2 e 2 : t’ 
7 1 h if eo then ei else e 2 if ei then ei else e 2 : r 
r, xo Xo : r 2 — > n, xi xi : r 2 h e e' : 

F I- fix xo(xi)e fix x' 0 (x'i)e' '■ t 2 t[ 

1 I- ei ei : r 2 — > n 1 b e 2 -^> e 2 : r 2 
7 1 b ei@e 2 ei@e 2 : 

7 h e-^e' : tJ t( = t 2 



r b e e' : t 2 
(VI < i < n)F b e e* : t/ 



fhe-vte 1 :t[ x ... x t( 



T I- poly e (ei, . . . , e' n ) : r[ X . . . X r' n 7h spec e TTi(e') : t/ 



Fig. 2. Standard type specialization 



Hughes m has proved the correctness of type specialization by specifying 
two reduction relations, one for two-level terms, -+ tt , and one for specialized 
terms, -+ sp , (see Fig. 0 and then proving a result like this: 

Proposition 1 (Simulation). If r b e\ ei : r' and e± -+ tt e 2 £/ien f/iere 
exists ei such that r b e 2 ei : t' and ei — > sp e' 2 ■ 

As in Hughes’s paper PI , the proof relies on a number of substitution lemmas 
(see Section 0, which are all easy to prove. 
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Reduction for two-level terms 
ni+n 2 -4« (ni + n 2 ) 

if 0 then ei else e 2 —>tt ei 
if 1 then ei else e 2 -4tt e 2 
(fix f(x)e i)@e 2 -4« 

ei[/ i — y f ix f(x)e i,x 1-4 e 2 ] 
spec (poly e) — e 

lift m+lift n 2 -4tt lift (ni + n 2 ) 

if 0 then ei else e 2 -4tt ei 
if 1 then ei else e 2 — >tt e 2 

( fix so(a;i)ei)@e 2 — 

ei[*o fix xo(xi)ei, xi i-4 e 2 ] 



Reduction for specialized terms 



ni+n 2 — > sp (ni + n 2 ) 

if 0 then e\ else e 2 -4 sp e'\ 

if 1 then e'\ else e 2 -4 3p e 2 

(fix *o(*i)ei)@e 2 -4 sp 

e'^xo i — y fix xo(xi)e[, xi i-4 e 2 ] 

'Xi (Cl , ■ ■ ■ i 6n) ^ sp 



Fig. 3. Notions of reduction 



||BaseType|| = BaseType 

j|(ri, . . . ,t„) -4 r|| = (U, ||ri||, . . . , ||r„||, {£, ||t||) -4 Ans) -4 Ans 
|r| = (U, (S, ||r||) -4 Ans) — > Ans 

Pll =0 

\\r,x-.T\\ = ||F||,x : ||r|| 

11*11 =* 

||a|| = a 

||f ix x 0 (xi . . . x„)e || = fix x 0 (a, xi, . . . , x n , x n +i)\e\(a, x n +i) 

M(ct,c) = c(cr, |H|) 

| (if ei e 2 e 3 )|(<r,c) = |ei|(er, A(<ri,yi).if yi then |e 2 | (cri , c) else |e 3 |(cri,c)) 

|0(ei . . . e„)| (cr, c) = |ei|(cr, A(ai, 2 /i) |e„| (a-„_i, A(cr„, y n ). 

let a' = <5(0)(ay l , y\ . . . y n ) in 

if a' = bad then halt() else c(a' ,0(yi, . . . ,y n ))) . . .) 

|e 0 @(ei . . .e„)|(cr, c) = |e 0 |(er, A(<T 0 , 2 /o).|ei|(<T 0 , A(<7 i,j/i) |e„|(cr n _i, \(a n ,y n ). 

yo@(<r n ,yi, . • ■ ,y n ,c)) . . .)) 

Fig. 4. Translation that enforces a security policy 



2 Enforcing a Policy by Interpretation 

A simple way to enforce safe execution is to incorporate a security automaton 
into an interpreter or a translation. Before attempting a primitive operation, a 
translated program steps the security state and checks whether the result is bad. 

Figure 0] shows a translation to continuation-passing and state-passing style 
m, augmented by stepping and testing of the security state. The translation 
makes explicit the flow of control and of the current security state. Using Ans as 
the type of answers, the translation acts on types as follows. 

Proposition 2. If T b e : r then | |P| | b |e| : \t \ . 
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The translated program never violates the security policy if the operations 
5(0) on the explicit state do not affect the state component in the operational 
semantics. Formally, let S' = (£, Op , Value, 5' ,cro, bad) with Op = Op U {5(0) | 
0 e Op} U {halt} (regarding 5(0) as the name of a new primitive) and, for all 
0 £ Op, 5'(0) = 5(0) and 5'(5(0))(u cr , Vi . . . v n ) = v a . Let |halt]() = a, a fixed 
constant signaling an error. 

A translated expression is safe with respect to S' and arbitrary o. 

Proposition 3. If a, \e\{a,\{a,y)y) {. a',v' then o' ^ bad. 

If the original term delivers a result without entering a bad state then so 
does the translated term. 

Proposition 4. Suppose o, e {. <r',v. If o' ^ bad then cr, |e|(cr, A(cr, z/)z/) 4- 
cr',|M|. 

If evaluation of the translated term leads to non-termination or to an unde- 
fined primitive operation then so does evaluation of the source term. 

Proposition 5. If there exist no o' and v 1 such that o, \e\(o, X(o,y)y) {. o' ,v' 
then there exist no o' and v' such that o, e f o' ,v' . 

Using this naive translation yields inefficient programs because every use of 
a primitive operation is preceded by a run-time check of the security state. 

3 Compiling Policies by Type Specialization 

To submit the translation to a specializer, we retarget it to a two- level language, 
indicating compile-time by overlining and run-time by underlining. Type spe- 
cialization H2 of the translated terms can remove the state component, o, and 
the corresponding run-time checks completely, in certain cases. 

We consider the two-level translation as an interpreter and specialize it with 
respect to a source program. The specialized program can be shown to be safe in 
two steps: Prove that translated programs are safe, and appeal to the correctness 
of the specializer (Prop, d) to see that the specialized programs are safe. 

3.1 First Steps 

Specialization potentially generates code variants for each different security 
state. Hence, it is only applicable if the set of states is finite. For further sim- 
plification, we initially assume that the transition function does not depend on 
the arguments but only on the name of the primitives. Hence, the compile-time 
transition function, 5, is well-defined and gives the full information: 

- 5(0)(ct) := o' if Vyi . . .y n .S(0)(o,y 1 , . . . ,y n ) = o', 

- 5(0)(ct) := bad if Vo' 3yi . . . y n .5(0)(o, j/i, . . . , y n ) ^ o’. 

Hence, the state becomes a compile-time value and all operations thereon 
can be computed at compile-time. Figure 0 defines the translation. It follows 
the basic strategy of Danvy and Filinski’s one-pass translation to continuation- 
passing style [X, ty . It avoids introducing administrative redexes by converting 
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|BaseType|| e = BaseType 

|(n, . . . ,r„) -¥ r|| e = polyjr, ||ri|| e , . . . , ||r„||e,poly (E, [lr[[ P ) -»Ans ) ->Ans 
r\ e = (E, (E, |[t|| b )=F Aiis )=F Aiis 

|0|| e = 0 

\r,x:r\\ e = ||r|| e ,x : ||r|| e 



IMU = x 

IHIe =a 

||fix xo(xi ... x„)e||e = poly fix xo(o, xi, . . . , x n , x„+i ) 

|e| e @(a, A(a, y).spec x n +i@(o,y)) 

| v\e(o,c) =c@(o L ||n|y 

| (if ei e 2 e3)|e(CT, c) = |ei| e @(CT, A(cti,j/i). 

if yi then \e 2 \ e @(oi ,c) else |e 3 | e @(o ; i, c)) 

|0(ei . . .e„)| e (ao,c) = |ei| e (o" 0 , A (oh, yi) |en | e , A(a„, y n ). 

let o' = 5(0) (<f n ) in 

if o' = bad then halt() else 

let y = Q{yi, ...,y n ) in c@(ct', y)) . . .) 

|e 0 @(ei . . . e„)| e (<7, c) = |eo|e@(o=, A(ct 0 , y 0 ). 

|ei| e @(o= 0 , A(cti, j/i) |e n | e @(CT n _i, A {o^,y n ). 

spec y 0 @(a n ,yi,...,yn,poly A (o,y).c@(o,y))) . . .)) 



Fig. 5. Two-level translation 



\(a,file, c)._ 
let o' = 5(read)(<r) in 
if ~=(o\ bad) then _HALT() else (1) 
let t/i = read (file) in 



poly A (o,file,c). 
let o' = 5(read)(c) in 
if ~=(o' , bad) then HALT O else (2) 
let y\ = read (file) in 
spec (c)@(cr', j/i ) 



Fig. 6. Translated example 



compile-time continuations to run-time ones, and vice versa, using eta-value 
expansion. The relevant terms are in the translation of fix and application: 
A(ct, j/).c@(ct, y) converts the compile-time continuation c to a run-time value 
and A(?J, y).spec y) converts the run-time continuation x n +\ into a 

compile-time one. 

Both the terms for fix and for application contain subterms of the form 
A(cf, x, . where a run-time function has a compile-time parameter, ef. This 
violates the well-formedness restriction of traditional partial evaluation uni and 
is the motivation for using type specialization altogether. 
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3.2 Polyvariance Matters 

To see, why the poly and spec annotations in the translation are required, 
consider a simple example term 



X(file)read(file) (3) 

and its translation Q) in Fig. 0. It has specialized type 

(S {before-read} , BaseType, (S {after-read} , BaseType)— >Ans)—»Ans 
when called in state before-read and type 

(S {after-read} , BaseType, (S {after-read}, BaseType) = >Ans)^Ans 



when called in state after-read. Since the types are different, the function cannot 
be used at both types at once. 

To overcome this restriction, Hughes introduced polyvariance. A polyvariant 
expression gives rise to a tuple of specializations, one for every different type of 
use. Hence the translation uses poly A (if, x, ...)... . which has specialized type 
((5 {(Ti}, B aseType, ...)-» t[) x ... x ((S'{ct„}, BaseType, ...)-» r^), for distinct 
<ji, ... ,a n . The set {a \, . . . , a n j contains only those states that actually reach 
a use of the polyvariant type. The specializer determines this set dynamically 
during specialization. A term spec . . . indicates an elimination point for a tuple 
introduced by poly . It selects a component of the tuple, based on the required 
type ( i.e ., the state at the elimination point). 

Using poly in the translation of (0) yields (EJ in Fig. EUwith specialized type 



((S {before-read,} , BaseType, (S {after-read} , BaseType)— s-Ans) — »Ans) 
x ((S {after-read}, BaseType, (S {after-read}. BaseType)— s-Ans)— >Ans) 



( 4 ) 



and specialized code 



(A(/zfe, c)let y\ = read (file) in c@{y i) 

, X(file, c)let yi = read(/)Ze) in c@(j/i)). 



3.3 Properties of the Translation 

The translation preserves typing. 

Proposition 6. If T b e : r then ||-T|| e b |e| e : \r\ e . 

We state the relation to the naive translation (Fig. El using the function 
eraseQ. It maps a two-level term to a standard term by erasing all overlining 
and underlining annotations as well as erase(lift e) = erase(e), erase ( poly e) = 
erase(e), and erase ( spec e) = erase{e). 

Proposition 7. cr, |e|(cr, A(cr, y)?/) 4- ^ilMI and only if 

a, erase{\e\ B )(a, X(a,y)y) 4_ a', erase (|M| e )- 
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|0(ei . . .e„)|Ho'o,c) 

= |ei|i(<?o ; M&i,Vi) |e n |i(a„_i, A (W„,y n ). 

let o' = 5(0) (o n ) in 

if o' ^ bad then c@(a', 0(yi , . . . , y n )) else 

let o = 5(0)(lift o„,yi, . . . ,y n ) in 

if <7= lift bad then halt() else 

let { o'i , ■ ■ ■ ,o' r } = ZifO)^) in 

let y = 0{y i, . ..,y n ) Jm 

if <7= lift o'i then c@(o[,y) else 

if <j= lift <7 2 then c@(o 2 ,y) else 

. . ,c@{o' r ,y)) . . .) 

Fig. 7. Revised heterogeneous treatment of primitive operators 



To relate to the compiled/specialized program, we invoke the correctness of 
the underlying specializer and conclude the safety of the compiled program. 

Proposition 8. Suppose 0 h trans e (oq, \(o,y).y) e! : t' where trans is 
the program text defining \ \ e . The compiled program e! is safe wrt. oq € S. 

Technically, Hughes’s correctness proof applies to type specialization for a call- 
by-name lambda calculus. This does not pose problems in our case, because we 
are only specializing programs in continuation-passing style. 



3.4 Achieving Generality 

Up to now, the state transition function did not depend on the arguments to 
the primitives. This restriction can be removed using the revised treatment of 
primitive operators in Fig. Q 

The code first evaluates and checks the arguments of the operation. If it 
can predict a potential security violation from the pre-computed security state, 
o', then it generates a run-time test using an implementation, 5 , of the state 
transition function applied to the run-time constant, lift o n , and the actual 
arguments. The resulting run-time security state, o, is tested against bad at 
run-time. Finally, it extracts a compile-time state from o using 

A(0)(cr) = {<5(0) (cr , 2 / 1 , ...,y n ) \yi,...,y n € Base} \ {bad} 

to estimate the set of possible non- bad. outcomes of the run-time state transition 
5(0) on the compile-time state <r. Using this set, the code recovers the compile- 
time value from the run-time outcome of the state transition by testing the latter 
against all possible values and using the compile-time value in the continuation. 
This is essentially “The Trick” eg, a standard binding-time improving trans- 
formation. It is a further source of code duplication because the continuation c 
is processed for each possible outcome. 
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Specialized types (revised) 
Kinding 



INT 



S{n} : INT 
t" : INT 



I A K ■ ■ ■ A 

n : INT t 2 : INT 



r : * 

(VI <i,j < n)r' 



Int ~ /nf : * 



A+rj : EVT 

/ // 
n ~ n 



^2 



7"l 

/ 

T 



• ^2 

// 

r 



' T i 



A 

Equality relation (additional rules) 



Tr = Ti 



1 r 2 : * 
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Subtyping relation (extending equality) 

i € {1, . . . , n} (VI < i < n)r' < t[ < A t[ < t " 

A [A , ■ ■ ■ , A] < T- t' < A [A , ■ ■ ■ , A] A A < A' -¥ T " 

Additional specialization rules 



r h e e' : A t' < t" 
T h e e ; : r" 



(VI <i< n)r h ei ei : A 
T, x a;' : A [A I 1 A * < n] h e 2 e 2 : r' 

E h let i = ei in e2 let A = ei in e2 : A 



Fig. 8. Type specialization with intersections and subtyping 



4 Compiling Policies Using Intersection Types 



The code generated from the translation (Fig. 0 can contain many identically 
specialized versions of a single function. This section proposes a remedy against 
this useless code growth. 

For a concrete example, let’s look again at the translation of X(file)read(file) 
in Fig. 0 (ID, its specialized types in ® and terms in ©• Despite the difference 
in the specialization types, the code is identical. It turns out that the function 
has an intersection type 00E3G7!: 



A 



(S^&e/ore-read}, BaseType, (5{ a/ter- read}, BaseType) — > Ans) — > Ans, 
(S {after-read), BaseType, (S {after-read}, BaseType) — > Ans) — > Ans 



. (6) 

This observation suggests an extension of type specialization with a restricted 
notion of intersection types and subtyping. The restriction is that intersection 
types can only be formed from structurally isomorphic types that differ in sin- 
gleton types, as formalized in Fig. 0 with the judgement t' ~ r" : *. 

In the running example, specialization with intersection types generates the 
same term X(file,c)let = Tead(file) in c@(y i) with type Q). 

The extended syntax of specialized types contains finite intersections of types. 
The rules defining t' = t" make equality compatible with intersection. Subtyping 
extends equality with the usual rules for intersection and function subtyping M- 
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The additional specialization rules include the standard subsumption rule, 
which eliminates intersection types where required. The introduction rule for 
intersection types requires a special let x = ei in e<± construct because its 
implementation incurs considerable expense. The type specializer processes the 
term e± for each demanded type t[ and checks that the resulting specialized term 
e\ is identical for each t[. If that is not possible, we must revert to poly variance 
and generate a new variant. Many functions are polymorphic with respect to the 
security state. In this case, the intersection typing generates exactly one variant. 

Finally, we have to extend the simulation result (Prop. Q) to the enriched 
language. Since there are no new reductions, it is sufficient to extend the proofs 
of the substitution lemmas m 

Lemma 1 (Source substitution). // f h ei e[ : t[ and r,x\ ^ e\ : r( b 
e 2 ^ : t 2 then T b e 2 [x\ e- >• ei] e' 2 : t 2 . 

Lemma 2 (Specialized substitution). Let 9 be a substitution that maps 
variables in specialized terms to specialized terms. If T b e ^ e! : t' then 

6(r) b 0(e') : r'. 

5 Conclusions 

We have shown that partial evaluation techniques are well-suited to translate 
programs into safe programs that observe security policies specified by security 
automata. We have exhibited a heterogeneous approach that eliminates most 
run-time security checks, but can result in code duplication. 

We have extended the type specializer by intersection types to avoid excessive 
code duplication in this approach. This refined approach automatically achieves 
all optimizations mentioned in Walker’s work m- A prototype implementation, 
which has been used to validate the examples in this paper, can be obtained 
from the author. 

In future work we plan to address the restriction to finite sets of security 
states by splitting them into compile-time and run-time components and to 
integrate the translation with our earlier work on run-time code generation m- 
The resulting framework will provide just-in-time enforcing compilation and it 
will serve for experiments with mobile code. 
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Abstract. This paper presents a definition of secure information flow. 
It is not based on noninterference, but on computational indistinguisha- 
bility of the secret inputs, when the public outputs are observed. This 
definition allows cryptographic primitives to be handled. This paper also 
presents a Denning-style information-flow analysis for programs that use 
encryption as a primitive operation. The proof of the correctness of the 
analysis is sketched. 



1 Introduction 

When is a program safe to run? One aspect of safety is confidentiality, which 
arises when the inputs and outputs of the program are partitioned into several 
different security classes. The typical classification of data is into public and con- 
fidential (of course, more complex classifications are also possible); for example, 
data that is received from or sent to a network may be treated as public, and 
data that is local to the site executing the program, as confidential. Our goal is 
to verify that an attacker who can observe the public outputs of the program 
cannot learn anything about the confidential inputs. In this case we say, that 
the program has secure information flow. 

What does it mean that an attacker can or cannot learn anything? There 
exists quite a large body of literature studying different instances of secure 
information flow, e.g., l;44Kni(l11liai:II1 411 fill hi . With the notable excep- 
tion of H5E3, security is defined through noninterference, i.e., it is required 
that the public outputs of the program do not contain any information (in the 
information-theoretic sense) about the confidential inputs. This corresponds to 
an all-powerful attacker who, in his quest to obtain confidential information, has 
no bounds on the resources (time and space), that it can use. Furthermore, in 
these definitions an “attacker” is represented by an arbitrary function, which 
does not even have to be a computable function; the attacker is permitted es- 
sentially arbitrary power. 

The approach of defining the concept of “secure information flow” by means 
of an all-powerful adversary does not allow for cryptographic primitives to be 
treated easily, as they are usually only computationally secure, but not informa- 
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tion-theoretically. Also, realistic adversaries are resource-bounded; hence this 
should be reflected in our definitions, especially if we can show that more pro- 
grams are secure by this means. 

The contributions of this paper are as follows: 

— A definition of secure information flow that corresponds to an adversary 
working in probabilistic polynomial time (in the following abridged as PPT ; 
where “polynomial” means polynomial in a suitable security parameteiQ). 
Our definition of secure information flow is stated in terms of program’s 
inputs and outputs only, in this sense it is similar to that of Leino and Joshi 

(■IdJj- 

— A program analysis that allows us to certify that the flow of information in 
the program is secure in the aforementioned sense. The programming lan- 
guage contains a binary operator “encrypt message x under the key /e”p. The 
analysis reflects that finding the message from the cryptotext is infeasible 
without knowing the key. 



2 Related Work 

The use of program analysis to determine information flow was pioneered by 
Denning HE]. She instrumented the semantics of programs with annotations 
that expressed which program variables were dependent on which other program 
variables. The definition of secure information flow was given in terms of these 
instrumentations | 5 ]. Also, she gave an accompanying program analysis. 

Volpano et al. M gave a definition of secure information flow without using 
any instrumentations. They define a program to be secure if there exists a sim- 
ulation of the program that operates only on the public variables and delivers 
the same public outputs. They also give a type system for certifying programs 
for secure information flow. 

Leino and Joshi m give a definition of secure information flow that makes 
use of programs’ inputs and outputs only. They define the program to be secure 
if the values of its secret inputs cannot be observed from its public outputs. 
Sabelfeld and Sands D3 and Abadi et al. PQ have given generalisations of this 
idea. However, none of these papers describes an accompanying mechanical ver- 
ification tool. 

Recently, Volpano and Smith punn have weakened the security definition a 
bit (it is no longer noninterference) to handle cryptographic primitives, namely 
one-way functions. However, there are two ways in which their definition might 
be considered unsatisfactory: 

— It is too restrictive in allowing the use of constructs that violate the nonin- 
terference condition. 

— The notion of security is too lax (in m Volpano allows the adversary to 
find out partial information about the confidential input value). 

1 by encryption, the security parameter is related to (and often defined to be equal 
to) the key length 

2 also contains a nullary operator “generate a new key” 
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Work has also been done to define and handle the integrity properties of data 
(e.g. pnj). These questions are outside the scope of this paper. 

Another work, which is not about secure information flow, but which has 
influenced the current paper, is that of Abadi and Rogaway 0 . They provide a 
computational justification of one part of the formal approach to cryptography 
namely to the construction of messages from simpler ones by tupling and 
encryption. The construction of messages could be viewed as a straight-line 
program; actually, if one only considers straight-line programs, then their results 
subsume ours. Because of our treatment of control flow, we have seemingly more 
restrictions on programs than they have. 

3 Syntax and Semantics 

The programming language that we consider is a simple imperative programming 
language (the WfflLE-language). Given a set Var of variables and a set Op of 
arithmetic, relational, boolean etc. operators, the syntax of the programs is given 
by the following grammar: 



P x := o(x i, ... ,x k ) 

I Pi;P 2 

if b then Pi else P2 
while b do Pi, 

where b,x,x 1, ... ,x k range over Var, o ranges over Op and Pi, P2 range over 
programs. We assume that there are two distinguished elements in the set Op 
a binary operator £nc ( £nc(k,x ) is the encryption of the message x under 
the key k ) and a nullary operator Sen (generating a new key). 

We also make use of flowcharts as the program representation. Each node of 
the flowchart contains either an assignment statement or a test. Additionally, we 
add an extra start- and an extra end- node to the flowchart. It should be clear, 
how a program P is converted to a flowchart. 

The semantics that we give for the programming language, is denotational 
in style. If State is the set of all possible internal states of the program, then 
the denotational semantics usually has the type State — »• State j^, i.e. it maps 
the initial state of the program to its final state. States := State l±l {_!_}, where 
T denotes non-termination. Moreover, one usually defines State := Var Val, 
where Val is the set of all possible values that the variables can take. The set 
Val is usually not specified any further. 

Furthermore, for defining the semantics of programs one requires that for 
each operator o € Op of arity k its semantics [o] : Val fc — > Val has already been 
defined. We want that [£nc] and [Sen] satisfy certain cryptographic definitions, 
namely the following: 

Definition 1 (from J2J). An encryption scheme (Gen, Enc)\^is which-key and 
repetition concealing, if for every PPT algorithm with two oracles the 

following difference of probabilities is negligible in n: 

3 This tuple should also have the third component — the decryption algorithm, but 
we do not need it for that definition 
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Pr[fc, k' <- Gen{ 1”) : ■)(!«) = i] _ 

Pr [k <— Gen(l n ) : = x ] . 

Here £(n) € Z[n] is a suitable length polynomial. An encryption system is thus 
which-key and repetition concealing, if no (polynomially bounded) adversary can 
distinguish the following two situations: There are two black boxes. 

1. Given a bitstring as the input, the boxes encrypt it and return the result. 
They use different encryption keys. 

2. The black boxes throw away their input and return the encryption of a fixed 
bit-string Q e ( n '> . Both boxes use the same encryption key. 

From this definition we see, that the structure of the semantics has to be 
more complicated than just having the type State — ► States . The issues are: 

— According to Def. Q Enc and Gen are not functions, but are families of 
functions, indexed by the security parameter n € N. Hence the semantics 
also has to be a family of functions, mapping a program’s inputs to its 
outputs. For each n we have to define a set State„ and the n-th component 
of semantics would map each element of State™ to State„^. 

— The algorithms Enc and Gen operate over bit-stringtfl. Therefore we specify 
State n := Var-> Val„ and Val„ := {0, 1}^"). 

— Clearly no family of deterministic functions satisfies Def. ^ the families 
of functions Gen and Enc have to be probabilistic. Thus the semantics of 
programs has to be probabilistic, too. Its n-th component maps each element 
of State™ to a probability distribution over State„^. We denote the set of 
probability distributions over a set X by V(X). 

There is one more issue. We are not interested in program runs that take 
too much time. The encryption scheme is defined to be secure only against 
polynomially bounded adversaries. Thus we are interested in only “polynomially 
long” program runs (i.e. the set of interesting runs may be different for different 
values of the security parameter). We support this discrimination by defining a 
previously described family of functions mapping inputs to outputs for each path 
in the flowchart from the start- to the end-node. Also, the (intuitive) meaning 
of _L changes. Instead of denoting non-termination it now means “control flow 
does not follow that path”. 

To sum it all up, the semantics [P]p a th of a program P has the type 
Path — > n ngN (State™ — ► X>(State„j_)), where Path denotes all paths in the 
flowchart of P from start to end. Also 

— for each operator o € Op of arity k the semantics of o is a family of (possibly 
probabilistic) functions [o] : ELeN^al™ — ► 2?(Val„)); 

— ([Sen], [£nc]) is a which-key and repetition concealing encryption scheme. 

4 this is not so explicit in the above definition, but it is the standard in complexity- 
theoretic definitions of cryptographic primitives 



Semantics and Program Analysis 



81 



start 




end 



Fig. 1 . Example for the semantics of paths 



To explain the semantics of the program at a certain path, look at the pro- 
gram P in Fig. □ Suppose that the semantics of the operator FlipCoin is such, 
that it returns either true or false with equal probability. Let the marked path 
be P. For each X; n i t , &i n ;t E Val„ we have 

X I ^ £mit + 2 

b i — ^ true 
X I ^ ^Tinit T 2 
b i — ^ false 

It should be clear from this example, how |P]p a th is calculated. We omit the 
further specifications from this paper. 

4 Confidentiality Definition 

The confidentiality definition expresses that something holds for all (long 
enough) polynomially long computations. This needs an exact definition of a 
polynomially long computation. 

Definition 2. A function § : N— iT(Path) is a polynomially long path-set, iff 
there exists a polynomial q £ Z[n], such that for all n, the length of the elements 
(paths) of S(n) is not greater than q(n). 
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We denote the set of all polynomially long path-sets by CPXLCP. The set TCCP is 
ordered by pointwise inclusion. 

Given a program P and a polynomially long path-set §, we can define, how 
P behaves on §. 



n£H 



[P] : CPXLCP — >• (State„ — *-D(State nJ _)) 

[P](S)(Sn,.) = 



Sn^ E [P]Path(P)(^„, s )(5„) 
PGS(n) 

-L^l- E lP](S)(5 n , a )(S n ) 

Sn^StatG n 



where n £ N, S rhs , S n £ State n . Thus the behaviour of P on a path-set is the 
“sum” of its behaviours on the elements of this path-set. The probability, that 
a final state S n is reached over § is the sum of probabilities that this state is 
reached over the elements of §(n). _L means, that the control flow does not follow 
any path in S(n). 

We are going to define, what it means, that certain outputs of the program 
do reveal something about a part (the confidential part) of the input to the 
program. What kind of object is this “part of the input”? In most general case 
it is just a family of functions c = {c n } ra6 N, c n : State„ — >-{0, 1}*. For example, 
if the set of variables has been partitioned into public and confidential variables, 
then c n (S n ) would return a tuple consisting of the values of all confidential 
variables in the state S n . As we are going to define computational security, we 
require, that c is polynomial-time computable, i.e. there exists an algorithm 6 
that works in polynomial time and 6(1™, S n ) = c n {S n ). 

Definition 3. A part c = {c n }„ e N of the input, given to program P is recover- 
able from the final values of the variables in Y C Var. given that the input to P 
is distributed accordingly to D s = {-D„ jS }„ e N, D UtS £ 2?(State„), iff there exists 
a polynomial-time computable predicate B = {-B n }raeN, B n : {0, 1}* — >-{0, 1} and 
a polynomially long path-set So £ J\ such that for all polynomially long path- 
sets S £ CPUCP, where S > So, there exists a PPT algorithm A, such that for all 
PPT algorithms 23 the following difference is not negligible in n: 



Pr[5ra,s t— D niS ,S n <— [P](S)(5' njS ) : A(l n ,S n \ Y ) = B n (c n (S n , s ))]- 

Pr[5„, s ^D„, s : B(l n )=B n (c n (S n , a ))] ■ 

Let us explain some points of this definition a bit: 

— We demand that after the program has run for long enough (but still poly- 
nomial!) time (3SoVS > So), its behaviour “stabilises” in the sense that 
nothing more will become or cease to be recoverable. 

— We demand that after this stabilisation, a property that is similar to the 
notion of semantic security (more exactly, to its negation) of encryption 
systems must hold for |P](S), with regard to c and Y. We require, that the 
final values of the variables in Y tell us something about c, that we did not 
know before. See [B, Sec. 5] (and also references therein) for the discussion 
of semantic security. 
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— The probability distribution of the inputs to the program has been made 
explicit in our definition. It has not usually been the case in earlier works 
(for example mm), where one has implicitly assumed, that the input 
variables are independent of each other. 

— The definition of recoverability is termination-sensitive, as the value S n that 
is picked accordingly to [P](§)(5 , „ iS ) may also be J_ (in this case define the 
contraction of _L to Y to be _L, too). However, it is not sensitive to timing. 

We say, that the program P is secure for the initial distribution D a , if the 
secret part of its input is not recoverable from the final values of the set of the 
public variables of P. 

5 Program Analysis 

We suppose that we have a fixed program P, the secret part of the input c that 
is calculated by the algorithm C in polynomial time, and the initial probabil- 
ity distribution D s . Before we present our analysis, let us state some further 
constraints to the programs and to the details of the semantics, that we have 
not stated before, because they had been unnecessary to give the definition of 
recoverability. For some of these constraints it is intuitively clear that they must 
be obeyed, if we talk about computational security. Some other constraints are 
really the shortcomings of our quite simple analysis (comparable in its power to 
the one in JJ]) and removal of them should be the subject of further work. 

— For each operator o G Op, the semantics of o must be computable in poly- 
nomial time, i.e. there must exist a polynomial-time algorithm 0, such that 
[o]„(0 = 0(1”, •) for all n. Otherwise we could have an atomic operation 
“crack the key” in our programming language .... Thus the necessity of this 
constraint should be obvious. 

— The probability distribution D s must be polynomial-time constructible, i.e. 
there must be a PPT algorithm D, such that the random variables D n s and 
D(l”) have identical distribution for each n. Without this requirement it 
might be possible to use the initial distribution as an oracle of some sort and 
thus answer questions that a PPT algorithm should be unable to answer. 

— Keys and non-keys must not be mixed, i.e., each variable in Var should have 
a type of either “key” or “data” and it is not allowed to substitute one for 
another. The output of S en and the first input (the key) of £nc have the type 
“key”, everything else has the type “data”. This has several consequences: 

• One may not use data as keys. This is an obvious constraint, because it 
just means that the used keys must be good ones, i.e. created by Sen. An 
extra constraint is that the initial values of the variables of type “key” 
must be good keys, too. 

• One may not use keys as data. This is a shortcoming of our analysis, 
that for example [2J (almost) does not have. We believe that using their 
techniques it is possible to get rid of that constraint. 

• There is no decryption operator. Also a shortcoming. We believe that 
by building definition-use chains between encryption and decryption op- 
erators it is possible to keep track, what could be calculated from the 
encrypted data, and to remove the shortcoming that way. 
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Fig. 2. Auxiliary nodes to separate control dependency regions 



— At each program point, it must be statically known, which keys are equal 
and which are not. This is probably the biggest shortcoming of our analysis. 
We defer its discussion to Sec. Q For each node N of the flowchart and each 
variable k with type “key” , we let E(7V, k ) C Var denote the set of keys that 
are equal to k at the node N. If the program satisfies this requirement, then 
one can compute E easily by using the methods of alias analysis, see, for 
example 0 Sec. 4.2.1 and 4.2.2]. Note that this requirement also generates 
a constraint on D s , similar to the case of requiring good keys. 

— The program P must run in expected polynomial time. Although our security 
definition is termination sensitive, our analysis is not. 

To handle the implicit flows more comfortably, we add dummy nodes (we call 
them merge- nodes) to the flowchart in those places where the control dependency 
regions end. Figure Cl explains adding merge- nodes to branches and while-loops. 
In this way the starts and ends of the control dependency regions are marked 
in the flowchart (starts with if , ends with merge) and we do not have to treat 
the edges going from one control dependency region to another differently from 
those that start and end inside the same region. 

The type of the analysis W is Node — »• ^(T (Var)), where Node is the set of 
the nodes in the flowchart and Var = Var U Nodeif, where Node if C Node is 
the set of all (/-nodes. Here fPu(3Q> where X is a partially ordered set, denotes 
the set of all such subsets of X that are upper closed. We will also make use of 
an operator clu(-) which, when applied to a subset of a partially ordered set, 
returns its upper closure. 

Y £ W (N), where N £ Node and Y C Var means that the analysis has 
determined that at node N the secret part of the input of the program may 
be recoverable from the values of the variables in Y D Var, if one also takes 
into account that at the nodes in Y n Node if the branch leading to the node 
N was chosen. Actually the (/-nodes in Y are used to track the implicit flow 
from the boolean variables that guard them. A better explanation can be given 
after presenting the transfer functions for if - and merge- nodes. The analysis may 
erroneously report that the secret part of the input is recoverable from Y, when 
in reality it isn’t. However, the analysis may not err to the other side. 
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We continue with presenting the transfer functions |iV] a bstr 5 where 
N £ Node. The type of these functions is obviously J’u(T(Var)) — > 3 3 u(J > (Var)). 
We start by giving two auxiliary functions (of the same type). Let x £ Var, 
X,YC Var, X <E ?u(:P(Var)). 

kill [a;] (X) = clu ({Z \ Z £X,x^Zj) 
flow [AT => y](X) = clu(X U {(Z\X) U {u} | Z £ X,v€ Y }) 

The meaning of the function kill [a:] should be obvious. The function 
flow [X => y] describes the flow of information from the variables in X to the 
variables in Y . It says, that if an adversary can find something from the values 
of the variables in the set Z , then after the information has flown, the properties 
of the values of the variables in Z (~l X, that the adversary makes use of, may 
also be derivable from the value of some variable in Y. 

— The node N is labeled with x := o(x i,... , X&), where o yf £nc. Assume 
w.l.o.g. that x is different from X \, . . . , x 

I-N] abstr = flow [{ail, ... , x k } => {x}] o kill [x] 

— The node N is labeled with x := tnc{k,y). We again assume that x yf y. 
Let K C Var, such that all variables in I\ have the type “key”. Define one 
more auxiliary function 

flow [X 4- y](X) = clu(X U [{Z\X) U {v, k} \ Z £ X,v £ Y,k £ K}), 

which describes the flow of information from X to Y, during which it becomes 
encrypted with some key from the set K. 

[-/V] abstr = flow [{j/} E( ^ fe) {x}] O kill [x] 

— The node N is labeled with if b. 

[Alabstr = fl0W [{6} =» {N}] 

— The node N is a merge- node. Let the corresponding z/-node be TV; f. Let 
Var asgn C Var be the set of variables that are assigned to somewhere be- 
tween iVjf and N. 



[Alabstr = kill [Nit] o flow [{./Vif} =► Var asgn ] 

Here we see how the implicit flow from a boolean variable to those variables, 
assigning to which it controls, is taken care of. (b => N -, f => Var asgn ) 

— The transfer function for the end - node is the identity function. 

— The node N is the start-node. What should be our initial analysis infor- 
mation? It must describe the initial probability distribution D s . For ex- 
ample, if the secret part c of the input is just the values of the variables 
from the set Var con f and according to D Sl all input variables are inde- 
pendent of each other, the initial analysis information must be at least 
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cludl#} | x G Var con f}). In general case (and formally), if Yj ., . . . ,1) C Var 
and there exist a polynomial-time computable predicate B = and 

a PPT algorithm with an oracle A^'>, such that for each PPT algorithm 3 
there exists an i, 1 < i < l, such that 

Pr [S n , s ^D U}S : A^ in Hl n ,i,S n}S \ Yi ) = B(c n (S. n , s ))] - 

Pr [S n , «<-£>„,» : ®(l n ) = B(c n (5„, s ))] 

is not negligible in n, then at least one of the sets Y \ , . . . , Yj must be an 
element of the initial analysis information. 

The set Tu^Var)) is obviously ordered by inclusion and the least upper bound 
is the set union. This completes the specification of the data flow analysis. 

6 Proof of Correctness 

Theorem 1. Let P be a program in the While -language, let Var be its set of 
variables and N en d be the node labeled with end in its flowchart. Let c be the 
secret part of the input to P. let D s be the probability distribution of the input, 
let Y C Var. Let the requirements in the beginning of Sec. 0 be satisfied and 
let W be the program analysis for P. c and D s . If c is recoverable from the final 
values of the variables in Y , given that the input to P is distributed accordingly 
to D s , then Y G W (N end ). 

The theorem thus says that if one can find out something about the secret in- 
put when observing certain outputs, then the analysis reports that these outputs 
give away secret information. 

We define some auxiliary notions to present a technical lemma. Let W : 
T(Var) — > Tu(T(Var)) be such, that W(X), where X C Var, equals W (N en d) 
if we take W(iV start ) to be equal to clu({X}) and calculate W(7V en d) by the 
analysis given in the previous section. Thus W(X) is the set of sets of variables 
that are “caused to be” in the analysis result for N en d by the presence of X in the 
initial analysis information. For Y C Var let M(Y) := {X C Var | Y G W(X)} 
and let M(V) be the set of all maximal elements of M(V). 

Lemma 1. Let P be a program. Let its flowchart be annotated with the assump- 
tions about the equality of keys (i.e. let E be fixed). Let q G Z[n\ and let § G CP-CCP 
be such, that a path P belongs to S(n) iff \P\ < q{n). 

There exist PPT algorithms {Ax}xcyar, such that 

— the input of Ax(l n , ■) is a function of type X— iVal ra ; 

— the output of A x is either T or a set Z C Var and a function f : 

Z — > Val„ . 
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For all initial probability distributions D s = {D n ,s}neNi which satisfies the 
annotations of the program and for which the expected running time of the pro- 
gram is bounded by the polynomial q, for all subsets Y C Var and all PPT 
algorithms D the following difference is negligible in n: 

( ^ Pr[S n , a «-£>„,„(£,/) <-A x (l n ,S n ,,\x) : 
x 'eSf(y) 

FCZA2)(l n ,S„, s ,/|y) = l]) - 

Pv[S n>s <-D n , s ,S n ^lP](S)(S ntS ) : D(l",5„, SJ 5„|r) = 1] ■ 

The lemma is proved by induction over the syntax of the WHiLE-language. 

The above lemma states an indistinguishability result ([6,, Sec. 5] discusses the 
relationship between semantic security and indistinguishability). Intuitively, the 
lemma claims that if we know only some of the program’s input variables, then 
we can still simulate the run of the program, by computing only the values of 
the variables that only depend on the values of known input variables. The final 
set of variables, whose values the algorithm knows at the end of the program, 
may depend on the chosen branches at z/-nodes. Also, the lemma claims that the 
sets Z that the algorithms Ax output, are in average not too small — for each 
Y C Var there are sets A' C Var, for which Ax outputs Z Df with significant 
probability. Moreover, we can recreate the distribution (S ntS , S n \y), where S nyS 
is the initial and S n the corresponding final state of the program, with the help 
of the algorithms Ax (at least for a computationally bounded observer). 

Ax works by executing the program (by following its flowchart) . If the next 
statement is x = o(x i, . . . ,Xk) and the algorithm currently knows Xi, . . . ,Xk, 
then it will also know x, otherwise it will forget x, except for encryptions, where 
the algorithm randomly generates unknown inputs. At statement if 6, if Ax 
currently knows 6, then it will enter the right branch, otherwise it will jump 
directly to the corresponding merge and forget the variables in Var asgn . 

Proof (of the theorem). Suppose that the secret part c is recoverable from the fi- 
nal values of Y. According to the definition of recoverability, there exists an algo- 
rithm A that does that. The lemma provides us with the algorithms {Ax}xcv ar- 
For each X C Var we construct an algorithm A'^ x - as follows: on input (1", /o) 
we first run Ax on the same input, which gives us a set Z and a function 
/ : Z — > Val n . We then check whether Y C Z and 

— if true, return A( 1", /|y); 

— if false, invoke the oracle and return whatever it returns. 

Let {Yi,... , Y/} be the set M(Y). Let A'^ be an algorithm, that on input 
(l",i,/o), where 1 < i < l runs the algorithm A'Q on (l™,/ 0 ). Let 23 be any 
PPT algorithm. We now claim that the following difference is negligible in n: 
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l 

(^Pr : A' ( '\l n ,i,S n , s \ Y J = B(c n (S n , s ))]) - 

i= 1 

(Pr [S n>a <- D n>s ,S n <- [P](S)(S n , 8 ) : A(l n ,S n \ Y ) = B n (c n (S n , s ))] + 
(l-l)Pi[S n , a i-D n , a : ®(l n ) = J B n (c„(5„, s ))]) . 

Thus there exists an i that Pr[5„ >s <— D n , s : yt®( 1 ")(l rl ) 5 njS |y 4 ) = 
B(c„(5 n>8 ))] is greater or equal or only negligibly less than 

yPr[5 n>a S„<-[P](S)(5 n , a ) : .A(l", S„|y) = B„(c n (5„, s ))] + 

Ldpr[5 n>s ^D„ >5 : 3(1") = J B„(c„(5„, s ))] 

but this is significantly greater than Pr[S„ )8 <— D„ >s : 23( 1”) = 5(cn(5 n>g ))] . 
Thus there exists a j, such that Y) is in the initial analysis information. But 
Y e W(lj) and thus F G YI{N en d). 

The claim follows from 

i 

^Pr[S„, s ^ .D„ iS : A' { '\l n ,i,S ntS \ Yi ) = B(c n (S n , s ))] = 

i= 1 

Pr[S„, s <- D ntS ,(Z,f) <- A x {l n ,S n , s \ x ) : 

X<=M(Y) 

Y CL Z f\ A(l n , f\ Y ) = B(c n (S n , s ))] + 
Pr[S n , s ^D n , s ,(Z,f)^Ax(l n ,S n , s \ x ):YgZf<B(l n ) = B(c n (S n>s ))]. 

xel(y) 

The lemma gives that the first summand is only negligibly different from 
Pr[S n , a <-D nta> S n i-lP]{$){S n , a ) : A(l n , S n \ Y ) = B n (c n (S n , s ))] . 

The second summand equals 

Y, Pr K,* <" D n,s ■ ®(1”) = S(C„(5„ ;S ))] - 
XeM(Y) 

Py[S n ,s^D n>s ,(Z,f)^A x (l n ,S n , s \x) : YCZXB(l n ) = B(c n (S n , s ))\, 

xel(y) 

where, according to the lemma, the second sum differs only negligibly from 
Prf'S'n.s c- D„ jS : 23(1”) = B(c n (S ntS ))] (and the first is |M(F)| = l times that). 
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kl := gen_key() 
if b then 



kl := gen_key() 
if b then 



k2 := kl 
else 



k2 := kl 
else 



k2 := gen_key() 
x := enc(kl, y) 



k2 := gen_key() 
xl := enc(kl, yl) 
x2 := enc(k2, y2) 



Knowing the equality of keys 



Knowing, which key was used 



Fig. 3. Example programs 



7 Discussion 

We have presented an analysis that, for a certain class of programs, can decide 
whether these programs have computationally secure information flow. As an 
example consider the program consisting of a single statement x : = enc (k, y) . 
Suppose that the variables k and y are secret and x is public. In this case, our 
analysis finds that the initial value of y can be recovered from the final value of 
y or from the final values of x and k. However, both of these possibilities require 
the knowledge of some secret output, and thus the program does not leak the 
value of y. 

Our analysis reports, that nothing about the initial value of y can be found 
from the final value of x. On the other hand, the initial value of y obviously 
interferes with the final value of x and thus an analysis using non-interference 
as its security criterion must reject this program. 

Statically knowing which keys are equal. We require that at all program 
points we can statically answer the question “Which variables of type ‘key’ are 
equal?” The reason for this requirement is that, by having a cryptotext and a 
key, it is usually possible to determine whether this cryptotext was produced 
with this key, because the encryption usually involves padding the message in a 
certain way, see, for example, |5j. At least our definitions allow this determination 
to be possible. As an example of using this information, see the program in the 
left of the Fig.0 In this case, the adversary can find the initial value of b from the 
final values of x and k2, which our analysis does not reflect. The adversary has to 
check whether x was generated by encrypting with k2 or not. The requirement 
placed on E guarantees that this extra information is already statically known. 

Intuitively, it may seem that as k2 is assigned to at statements whose execu- 
tion is controlled by b, the variable k2 should be recorded to be dependent on 
b after the if-then-else-statement. Actually k2 is just a newly generated key 
at this place, thus, according to our semantics, it is not dependent on anything. 
On the other hand, the pair (kl, k2) depends on b. Unfortunately we are not yet 
able to handle such dependencies. 

Still, we believe that even the class of programs satisfying all the constraints 
given in the beginning of Sec.0is interesting enough — and moreover, big enough 
— to contain realistic programs. 
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Requiring which-key and repetition concealedness. The question nat- 
urally arises, why do we require such properties from the cryptosystem that we 
use. The example in the right of Fig. 0 shows that which-key concealedness is 
indeed necessary (at least when we use the analysis presented in Sec. 0 ). If the 
encryption was not which-key concealing, then the adversary might be able to 
determine whether xl and x2 were encrypted under the same key or not. This 
allows him to find the initial value of b. The analysis does not account for this. A 
similar example would show the necessity of repetition-concealedness. Although 
Abadi and Rogaway @ show that which-key concealedness is not hard to achieve, 
it would be interesting to study what could be done (how should the analysis 
look like) with weaker encryption primitives — especially with ones that are not 
repetition-concealing . 

Modeling secure information flow with noninterference. It is easy to 
write down an information-theoretic analogue to the definition of recoverabil- 
ity — it would look similar to Cohen’s JS] strong dependency, especially to its 
deductive viewpoint. One can also give similar program analysis and prove the 
corresponding correctness result. The analysis Wni would look identical to W; 
the only difference would be the absence of the special handling of encryption. 
The correctness proof would actually be simpler than the one presented in Sec. 
0 the lemma Cl would be easier to state, because the entities Ax, X C Var, 
would not be constrained to be PPT algorithms. 

Comparison to Denning’s and Myers’s abstract semantics. Observing 
the analysis Wni, we see that the minimal elements of Wni(-ZV) £ CPu(3 3 (Var)) 
are all one-element sets. Thus, we could replace the set ^(^(Var)) with 
T(Var) (by identifying the set clu({{£i}, • • ■ , {xfc}}) £ J’u(3 3 (Var)) with the set 
{xi,... ,Xk} £ T(Var)). We continue by replacing T(Var) with Var— >{L,H} 
by considering the characteristic functions X{ Xl ,... ,x k } • Var— ^{0,1} and identi- 
fying 0 = L, 1 = H. This gives us Denning’s and Denning’s 0 information flow 
analysis for the two-element lattice of security classes, also stated in their terms. 

On covert flows. Our analysis is not termination-sensitive — it does not 
detect that a program’s secret inputs may affect whether it terminates. Actually, 
termination is an issue if the security of the information flow is defined through 
noninterference. When using our definition, one needs to detect whether the pro- 
gram runs in polynomial time or not. Reitman and Andrews H3 have presented 
an axiomatic approach for checking the security of information flow, their method 
is termination sensitive and the way it has been made termination-sensitive is 
very explicit. Thus we should be able to apply their ideas to our analysis to 
make it termination-sensitive (or “superpolynomial-running-time-sensitive”) as 
well. Another possible covert channel that we do not address is how long the 
program runs and what can be detected from its timing behaviour. 

Acknowledgements. We are thankful to Reinhard Wilhelm and Thomas W. 
Reps. Their comments have certainly made this paper more readable. 
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Abstract. Languages for intensional type analysis permit ad-hoc poly- 
morphism, or run-time analysis of types. However, such languages re- 
quire complex, specialized constructs to support this operation, which 
hinder optimization and complicate the meta-theory of these languages. 
In this paper, we observe that such specialized operators need not be 
intrinsic to the language, and in fact, their operation may be simulated 
through standard encodings of iteration in the polymorphic lambda cal- 
culus. Therefore, we may more easily add intensional analysis operators 
to complicated languages via translation, instead of language extension. 



1 Introduction 

Consider a well-known inductive datatype (presented in Standard ML syntax [14] 
augmented with explicit polymorphism): 

datatype Tree = Leaf I Node of Tree * Tree 
Treerec : Va. Tree -> a -> ( a * a -> a ) -> a 

Leaf and Node are introduction forms, used to create elements of type Tree. 
The function Treerec is an elimination form, iterating computation over an 
element of type Tree, creating a fold or a catamorphism. It accepts a base case 
(of type a) for the leaves and an inductive case (of type a * a -> a) for the 
nodes . For example, we may use Treerec to define a function to display a Tree. 
First, we explicitly instantiate the return type a with [string] . For the leaves, 
we provide the string "Leaf", and for the nodes we concatenate (with the infix 
operator ~) the strings of the subtrees. 

val showTree = fn x : Tree => 

Treerec [string] x 
"Leaf" 

(fn (sl:string, s2:string) => "Node(" si ~ s2 ")") 

* This paper is based on work supported in part by the National Science Foundation 
under Grant No. CCR-9875536. Any opinions, findings and conclusions or recom- 
mendations expressed in this publication are those of the author and do not reflect 
the views of this agency. 
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As Tree is an inductive datatype, it is well known how to encode it in the 
polymorphic lambda calculus [1]. The basic idea is to encode a Tree as its 
elimination form — a function that iterates over the tree. In other words, a Leaf 
is a function that accepts a base case and an inductive case and returns the 
base case. Because we do not wish to constrain the return type of iteration, we 
abstract it, explicitly binding it with Aa. 

val Leaf = Aa. fn base: a => fn ind:a * a -> a => base 

Likewise, a Node, with two subtrees x and y, selects the inductive case, passing 
it the result of continuing the iteration through the two subtrees. 

val Node (x:Tree) (y:Tree) = 

Aa. fn base: a => fn ind:a * a -> a => 

ind (Treerec [a] x base ind) (Treerec [a] y base ind) 

However, as all of the iteration is encoded into the data structure itself, the 
elimination form only needs to pass it on. 

val Treerec = Aa. fn x : Tree => fn base : a => 

fn ind : a * a -> a => x [a] base ind 

Consequently, we may write Node more simply as 

val Node (x:Tree) (y:Tree) = 

Aa. fn base: a => fn ind: a * a -> a => 
ind (x [a] base ind) (y [a] base ind) 

Now consider another inductive datatype: 

datatype Type = Int I Arrow of Type * Type 

Typerec : Va. Type -> a -> ( a * a -> a ) -> a 

Ok, so we just changed the names. However, this datatype (or at least the in- 
troductory forms of it) is quite common in typed programming languages. It is 
the inductive definition of the types of the simply-typed lambda calculus. 

r ::= int | r — > r 

Just as we may write functions in ML to create and manipulate Trees, in 
some languages, we may write functions (or type constructors ) that create and 
manipulate Types. These functions over Types must themselves be typed (we 
use the word kind for the types of types). If we use Type (notated by Q) as the 
base kind, we get what is starting to look like the syntax of the kinds and type 
constructors of Girard’s language F u [8]. 

(kinds) k ::= J? | n — > n 

(type constructors) r ::= int | r — > r | a | A cck.t \ tt 

The language Af L [9] adds the elimination form Typerec to this type con- 
structor language. Because Typerec may determine the structure of an abstract 
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(kinds) k, ::= Q \ Ki — >• K2 

(type constructors) c, r ::= a \ XaiK.c | c\Ci \ int | n — > T2 \ 

Typerec[n] r c t c_> 

(types) 0 ::= T(t) \ R(t) \ ai — > <72 \ Vcuk.ct 

(terms) e ::= i \ x \ X x:a.e \ eie2 

| Aa:n.e | e[c] | R, \ R _+ 

| typerec[c] e ei 



Fig. 1 . Syntax of of the source language, Xr 



type, its operation is called intensional analysis. Furthermore, Xf L also allows 
the definition of a fold over a Type to create a term, with the special term 
typerec. With this term, Xf L supports run-time type analysis, as the identities 
of type constructors affect run-time execution. For example, just as we defined 
a function to print out trees, we can define a function to print out types at run 
time. 



val showType = Ala: 17. 
typerec [string] a 
"int" 

(fn (sl:string, s2:string) => "(" si ~ " -> " ~ s2 ")" 



Even though the type constructor Typerec and the term typerec are very 
specialized operators in X ML , they are just folds over an inductive data struc- 
ture. And just as we can encode folds over Trees in the polymorphic lambda 
calculus, we can encode folds over Types. Note that to encode the type construc- 
tor Typerec, we will need to add kind polymorphism to the type constructor 
language. 

In the rest of this paper, we will demonstrate how to encode a language 
with intensional type analysis operators into a variant of F u augmented with 
kind polymorphism. The fact that such an encoding exists means that the spe- 
cialized operators typerec and Typerec do not need to be an intrinsic part of a 
programming language for it to support intensional type analysis. Therefore, we 
may more easily add these operators to complicated languages via a translation 
semantics, instead of through language extension. 

The rest of the paper is organized as follows. Formal descriptions of the 
source and target languages appear in Section 2, and we present the embedding 
between them in Section 3. Section 4 describes the limitations of the translation 
and discusses when one might want an explicit iteration operator in the target 
language. Section 5 discusses related work and concludes. 
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Constructor Typerec 
Formation 

A b r : U 
A\~ c t : K 
A b c_» 

A b Typerec [k] t Ci c_» : k 

Constructor equivalence 

A b Typerec[n\ int Ci c-> = Ci : k 

A b Typerec [k](ti — » r 2 ) Ci c_> = 
c_» ( Typerec [k] n C; c_>) 

( Typerec [k] t 2 Ci c_>) : k 



Term typerec 

Formation 

A ; rbc:fl->fl 
A; T b e : R(t) 

A;fbe, : T(c(int)) 

A; r b e_j. : Va:l?.V/3:12. T(ca — > c/3 — > c(a 



/ 3 )) 



A; T b t?/perec[c] e e ; e_t : T{ct) 

Operational semantics 

typerec[c\ R t e t e_» i->- e; 

ft/perec [c] (FU[ti][t 2 ] «i w 2 ) ej h-» 
e_> [n][r 2 ] (t?/perec[c] ui e_») 
(t)/perec[c] u 2 e< e_>.) 



Fig. 2. Typerec and typerec 

2 The Languages 

Instead of directly presenting a translation of Xf L , we instead choose as the 
source language Crary et al.’s X R [5]. Because we will define two elimination 
forms, typerec and Typerec, we will need to separate type information used at 
the term level for run-time type analysis from that used at the type constructor 
level for static type checking. The language X R exhibits this separation by using 
terms that represent type constructors for analysis at run time, reserving type 
constructors for type-level analysis. A translation from Xf L into A H provides term 
representations (suitable for typerec) for each type constructor abstracted by the 
source program. 

To avoid analyzing quantified types, the core of X R is a predicative variant of 
F u . The quantifier \/a:K.cr ranges only over “small” types which do not include 
the quantified types. Therefore, the syntax (Figure 1) is divided into four syn- 
tactic categories: type constructors described by kinds , and terms described by 
types. By convention we use the meta- variable r for constructors of kind 17 (those 
equivalent to unquantified types) and c for arbitrary constructors. A constructor 
t of kind 17 may be explicitly coerced to a type with T(t). 

The semantics of X R includes judgments for type constructor formation A b 
c : k, type constructor equality A b c\ = C 2 : k, type formation Aha, type 
equality A b a\ = a%, term formation A; T b e : er and small-step operational 
semantics e i— » e' . In these judgments, A and T are contexts describing the kinds 
and types of the free constructor and term variables. 

The semantics of the type constructor Typerec and term typerec appears in 
Figure 2. Unlike Xf L , the argument to typerec is a term representing a type 
constructor, not the type constructor itself. The type R(t) describes such a 
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term representing r. The type is singular; for any r, only one term inhabits 
R(t). Therefore, once the identity of a term of type R(t) is determined, so is 
the identity of r. For example, if x : R.(a) and x matches the representation of 
the type int , denoted R h then we know a must be int. 

Arrow types in A H are represented by the term. This term requires the 
two types of the subcomponents of the arrow type and the two terms representing 
those types. 

: Va:i7.V/3:i7. R.(cx ) — > l?(/3) — t Ripi — > /3) 

For example, the type int — > int is represented by the term 

#-► [int] [int] R t R t 

One extremely useful property of typerec not illustrated by the showType 
example from Section 1, is that the types of the e, and e_> branches to typerec 
may depend on the identity of the analyzed type. If the argument to typerec is 
a term of type R(t), the result type of the expression is T(ct), where c may 
be an arbitrary type constructor. (The typerec term is annotated by c to permit 
syntax-directed type checking.) However, instead of requiring that the e, be of 
type T(ct), it may be of type T(cint), reflecting the fact that in e, branch we 
know r is int. Likewise, the return type of the e_> is T{c{a — > /?)), for some a 
and (3. 

There are several differences between A H presented in this paper and the 
language of Crary et al. [5]. To simplify presentation, this version is call-by- 
name instead of call- by- value. Also, here the result of typerec is annotated with 
a type constructor, instead of a type. However, we make two essential changes to 
support the embedding presented in this paper. First, we prevent fi-types from 
appearing as an argument to typerec or Typerec , by making R a part of the type 
language, and not a type constructor. We discuss in the next section why this 
restriction is necessary. 

Second, although typerec and Typerec usually define a primitive recursive fold 
over kind fi (also called a paramorphism [12,11]), in this language we replace 
these operators with their iterative cousins (which define catamorphisms) . The 
difference between iteration and primitive recursion is apparent in the kind of 
c_> and the type of e_> . With primitive recursion, the arrow branch receives four 
arguments: the two subcomponents of the arrow constructor and two results 
of continuing the fold through these subcomponents. In iteration, on the other 
hand, the arrow branch receives only two arguments, the results of the continued 
fold. 1 We discuss this restriction further in Section 4.1. 

The remainder of the static and operational semantics for this language, and 
for the primitive recursive versions, typerec pr and Typerec pr , appear in Appen- 
dices A.l and B. For space reasons, we omit the formation rules for types and 
type constructors, as they may be inferred from the rules for equality. 

1 Because we cannot separate type constructors passed for static type checking, from 
those passed for dynamic type analysis in \ f L , we must provide the subcomponents 
of the arrow type to the arrow branch of typerec. Therefore, we cannot define an 
iterative version of typerec for that language. 
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(kinds) k :: = ft \ K\ — » k 2 \ x I Vx*« 

(con's) c,t :: = a \ \a:n.c | C1C2 | Ax- C | c[k] 
| ini | 7i — > T 2 | Va:/t.r 

(terms) e :: = i | x | Ax:r.e \ eie2 
| Aoc.K.e | e[c] 



Fig. 3. Syntax of the target language, AF 



The target language of the translation is At/ - , the language F u augmented 
with kind polymorphism at the type constructor level (Figure 3). As the target 
language is impredicative, both types and type constructors are in the same 
syntactic class. In Section 4.2 we discuss why we might want alternate target 
languages not based on impredicative polymorphism. The static and operational 
semantics of A U~ appear in Appendices A. 2 and C. 



3 The Translation 

The translation of A R into A U~ can be thought of as two separate translations: 
A translation of the kinds and constructors of X R into the kinds and constructors 
of A U~ and a translation of the types and terms of X R into the constructors and 
terms of XU~ . For reference, the complete translation appears in Figure 4. 



3.1 Defining Iteration 

To define the translation of Typerec we use the traditional encoding of inductive 
datatypes in impredicative polymorphism. As before, we encode r, of kind 1? as 
its elimination form: a function that chooses between two given branches — one 
for c^, one for c_>.. Then Typerec[n \ r c_>. can be implemented with 

HIM] M [c_v ] 

As r is of kind type, we define [17] to reflect the fact that [r] must accept 
an arbitrary kind and the two branches. 

M = Vx-x -a (x x x) x 

Accordingly, the encoding of the type constructor int just returns its first argu- 
ment (the kinds of the arguments have been elided) 

[int\ = (Ax-Xi.Xa.b) 

Now consider the constructor equality rule when the argument to Typerec is 
an arrow type. The translation of the arrow type constructor — should apply 
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the second argument (the c_>. branch) to the result of continuing the recursion 
through the two subcomponents. 

In ->■ nj = ylx.Ai.Aa.a([ri][x] i oO([t 2 ][x] &) 

A critical property of this translation is that it preserve the equivalences that 
exist in the source language. For example, one equivalence we must preserve from 
the source language is that 

\Typerec\n] (n n r 2 ) q c^] = [c_» ( Ty perec [ k] n c z c^)(Typerec[n} r 2 c* c_>)| 
If we expand the left side, we get 

(Ax.Ai.Aa.a(In][x] i a) ( INI [x] <*)) [[«]] In] Ic-v] 

This term is then /3-equivalent to the expansion of the right hand side. 

[c->] ([nMMHnMc-y]) (InHWlInllc^.]) 

Because type constructors are a separate syntactic class from types, we must 
define IT(t)], the coercion between them. We convert Jr] of kind 1 1?] into a 
Ai7 _ constructor of kind 17 using the iteration built into Jr] . 

[T(t)J = [t] [17] int (Aa:l7.A/3:l7.a — > 0) 

For example, 

[T'(mt)] = \int\ [17] int (Aa:l7.A/3:l7.a — > 0) 

= (ylx.Ai.Aa.i)[l7] int (Act:l7.A/3:l7 .a —> 0) 

=0 int 

We use a very similar encoding for typerec at the term level, as we do for 
Typerec. Again, we wish to apply the translation of the argument to the trans- 
lation of the branches, and let the argument select between them. 

{typerec [c]e e* e_>] as [e] [[c]] [ej [e^.] 

The translations of R 4 and are analogous to those of the type con- 

structors int and — >. However, there is a subtle point about the definition of 
R.(t), the type of the argument to typerec. To preserve typing, we define [j?(r)J 
as: 

V7 : Il7 -> nj-lTinf int)} 

IVa:l7.V/3:l7. T(ja) T(7/3) -> T(7(a /?))] 

->• IT(7t)] 

Here we see why R cannot be a type constructor; if it were, we would have 
an additional branch for it in the translation of T mapping the R constructor 
to the R type. So the definition would be 

[T(r)] = [r] [17] int (Ac*: 12. A/3: 17.C* -► 0) (Aa:17. R(a)) (WRONG) 

causing the definition of Ii?(r)] to be recursive. 
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Kind Translation 

m 

Hi — > K 2 ] 

Constructor Translation 



H 

[Aa:K.c] 

Icic 2 ] 

\int\ 

In -»■ n] 

\Typerec[n] r C; c^] 

Type Translation 

lT(r)] 

lR(r)i 



lint 1 

[cti -S- cr 2 ] 
[Va:K.cr] 

Term Translation 



1*1 

[Ancr.e] 

[eie 2 ] 

[yla:/v.e] 

He]] 

Ift] 

H-i] 



[t?/perec[c] e e; e_>] 



Vx-x ->(x->x->x)-^x 

I'm] ~ ► Ha] 



a 

Aa:[K].[c] 

HMC2] 

Ax.At:x-Aa:x -> X X-t 

/lX.At:x-Aa:x -»■ X X- 

a ([n] [x] 1 «) ([r 2 ] [x] t a) 

H [Ml [ci] [c_>] 



[r] [17] int {Xor.fi .a -¥ (3) 

Vr-l n Ml-lTi'y int)J 

-»• [Va:17.V/3:17. Tiya) -»• T(7/3) -> T{^{a -¥ /3))] 

-> IT(7 t)] 

int 

Hi] -»■ H2] 

Vac HI -HI 



As: H] -HI 

[ei][e 2 ] 

Aa:[/t].le] 

Nile]] 

(T7:[l7 — > 17].A*:[T(7 inf)]. 

Aa:IVa:17.V/?:l7. T{"/ct) T( 7/3) — » T( 7 (a — )• /3))].i) 
/la: [17] .A/3: [17] . Axi : [i?(a)] • Ax 2 : [#(/?)] 

(-A7: [17 -»• 17].A*:[T(7 inf)]. 

Aa:[Va:l7.V/3:17. T( 'yet) -7 Ti'yfd) -7 T( 7 (a — >• /?))]. 
a [a] [/3] (*1 [7] * a) (z 2 [7] i a)) 

HI [HI] HI H->] 



Fig. 4. Translation of A« into XU 
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3.2 Properties of the Embedding 

The translation presented above enjoys the following properties. Define [Z\] as 
{a:[Z\(a)] | a £ Dom(A)} and [T] as (a;:[r(a;)] | x £ Dom(r)}. 

Theorem 1 (Static Correctness). 

i- 0 1 - [«] 

2. If A b c : k then [z\] b [c] : [k] . 

3. If A\- c = d : k then [zi] b [c] = [c'] : [k] . 
f. If A\- a then [Z\] b [cr] : 17. 

5. If A b a = a' then [A] b [cr] = [cr'] : 17 

6. If A; rh e: a then {A; f] h [e] : [cr] . 

Proof is by induction on the appropriate derivation. 

Theorem 2 (Dynamic Correctness). If 0 b e : cr and e £ e* then [e] i— »•* 

le'l 

Proof is by induction on 0 b e : a. 

4 Discussion 

Despite the simplicity and elegance of this encoding, it falls short for two reasons, 
which we discuss in this section. 

4.1 Extension to Primitive Recursion 

At the term level we could extend the previous definition of typerec to a primitive 
recursive version typerec pr by providing terms of type R.(a) and R(/3) to e_>. In 
that case, [i?(r)J must be a recursive definition: 

Vy:[17 12].[T(7 int)\ 

[Va:17.V/3:17. R{a) R{(3) T^a) T{^/3) -> T{j{a -> /?))] 

-»• lT(yr)] 

We have defined [i?(r)J in terms of [f?(a)] and [ij (/?)]. We might expect that 
a realistic term language include parameterized recursive types. In that case, the 
definition of typerec pr is no more difficult than that of typerec; just supply the 
extra arguments to the arrow branch. In other words, 

lR-+] = Aa:[17].A/3:[17].Axi:[j?(Q)].Ax 2 :[7?(/3)]. 

Ay: [17 — > 12].Ai.Aa. 
a[a\[(3\ xi x 2 (xi[ 7 ]ia)(a’ 2 [ 7 ]ia) 

However, we cannot add recursive kinds to implement primitive recursion at 
the type constructor level without losing decidable type checking. Even with- 
out resorting to recursive types, there is a well known technique for encoding 
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primitive recursion in terms of iteration, by pairing the argument with the result 
in the iteration. 2 Unfortunately, this pairing trick only works for closed expres- 
sions, and only produces terms that are (3i )— equivalent in the target language. 
Therefore, at the term level, our strong notion of dynamic correctness does not 
hold. Using this technique, we must weaken it to: 

If 0 h e : cr and e < e' then [e] is /^-convertible with [e'J. 

At the type-constructor level, /^/-equivalence is sufficient. However, for type 
checking, we need the equivalence to extend to constructors with free- variables. 
The reason that this trick does not work is that A U~ can encode iteration over 
datatypes only weakly; there is no induction principle for this encoding provable 
in At/ - . Therefore, we cannot derive a proof of equality in the equational theory 
of the target language that relies on induction. This weakness has been encoun- 
tered before. In fact, it is conjectured that it is impossible to encode primitive 
recursion in System F using /3r/-equality [22]. A stronger equational theory for 
At/ - , perhaps one incorporating a parametricity principle [19], might solve this 
problem. However, a simpler way to support primitive recursion would be to 
include an operator for primitive recursion directly in the language [13,18,3,4]. 

4.2 Impredicativity and Non-termination 

Another issue with this encoding is that the target language must have impred- 
icative polymorphism at the type and kind level. In practice, this property is 
acceptable in the target language. Although, impredicativity at the kind level 
destroys strong-normalization [2], intensional polymorphism was designed for 
typed-compilation of Turing-complete language [9], and impredicativity at the 
type level is vital for such transformations as typed closure conversion. Further- 
more, Trifonov et al. show that impredicative kind polymorphism allows the 
analysis of quantified types [23] . Allowing such impredicativity in the source lan- 
guage does not prevent this encoding; we can similarly encode the type-erasure 
version of their language [21]. 

However, the source language of this paper, \ Rl is predicative and strongly- 
normalizing, and the fact that this encoding destroys these properties is unsat- 
isfactory. It seems reasonable, then, to look at methods of encoding iteration 
within predicative languages [16,7]. In adding iteration to the kind level, strict 
positivity (the recursively bound variable may not appear to the left of an arrow) 
may be required [3], to prevent the definition of an equivalent paradox. 

5 Related Work and Conclusions 

Bohm and Berarducci [1] showed how to to encode any covariant datatype in 
the polymorphic lambda calculus. A variant of this idea, called dictionary pass- 
ing, was used to implement ad-hoc polymorphism in the language Haskell [17] 

2 See the tutorials in Meertens [11] and Mitchell [15] Section 9.3 

3 Coquand [2] originally derived a looping term by formalizing a paradox along the 
lines of Reynolds’ theorem [20] , forming an isomorphism between a set and its double 
power set. Hurkens [10] simplified this argument and developed a shorter looping 
term, using a related paradox. 
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through type classes [24]. In Standard ML [14], Yang [25] similarly used it to 
encode type-specialized functions (such as type-directed partial evaluation [6]). 
Because core ML does not support higher-order polymorphism, he presented his 
encoding within the ML module system. 

At the type constructor level, Crary and Weirich [4] encoded the Typerec 
construct with a language supporting product, sum and inductive kinds. Their 
aim was to support type analysis in type-preserving compilation. Because various 
intermediate languages do not share the same type system, they needed some 
way to express the analysis of source-level types within the target language. 

In this paper we demonstrate that all of these encodings are related, and 
have the implementation of iteration at their core. While intensional type anal- 
ysis seems to require highly specialized operators, here we observe that it is no 
more complicated to include than iteration over inductive datatypes. Though we 
have implemented such iteration via the standard encoding into the polymorphic 
lambda calculus, other constructs supporting iteration suffice. In fact, alterna- 
tive operations for iteration may be necessary in situations where impredicative 
polymorphism is not desirable. 

Acknowledgments. Thanks to Robert Harper, Bratin Saha, Karl Crary and 
Greg Morrisett for much helpful discussion. 
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A Operational Semantics 

A.l A„ 



(Xa-.x.e)e' e[e /x\ 

( Aa\K.e)[c] h-> (e[c/a]) 

ei i-» e\ e i — » e' 

eie 2 e[e2 e[c] e'[c] 



typerec pr [c\ R, d e ei 



typerec pr [c] (_R^[ri][r 2 ]ei e 2 ) e, e^ h- 1 
e-i[n][r 2 ] ei e 2 
(ft/perec pr [c] ei ei e_>) 

(typerec pr [c] e 2 e t e->) 

ei-> e' 

typerec pr [c] e e ; e^ h> 
typerec pr [c ] e' e* e_» 



A. 2 At/“ 



( Xx:c.e)e e\e /x\ 



ei e'i 
eie 2 i — ^ eie 2 



(. Aa\K.e)[c ] (e[c/a]) 

e^e' 
e[c] e'[c] 
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B Static Semantics of X R 

B.l Constructor Equivalence 




A, oc.u' b ci : k A\- C2 '■ k' 
a 0 Dom(A) 

A b (\a:n' .ci)c2 = ci[c2/a] : k 

A b c : Ki — > K2 
a 0 Dom(A) 

A b Aq:/ci .ca = c : Ki — > K2 

A, a\K b c = c 1 : k' 

A b A cr.K.c = Xa:K.c' : k —y k' 

A b Cl = c'i : k' —¥ K A b C2 = c' 2 : k! 
A b C1C2 = C1C2 : K 

A b Cl = c'j : k! — > K A\- C2 = c'2 ■ n' 

A b Cl — ^ C2 — Cl — y C2 • 1? 



Abe:); 

A \- c = c : k 

A b c' = c : k 
A b c = c' : k 

A \~ c = c' : k A h c' = c” : k 
A \~ c = c" : k 



B.2 Type Equivalence 




A b Ci = C2 : K 
A b T(C i) = T(c 2 ) 

Zl b Cl = C 2 : K 

/A b fl(ci) = R(c 2 ) 

A b (Ji = a'i Ah a 2 = a' 2 
A b (T 1 — y = & 1 — y Cr '2 

A h T(int) = int 

A b (7i = T(ci) A b (72 = T{c 2 ) 
A b ci — y a 2 = T(ci — > C2) 
zA, a:/t b a — a' 

A b Va:/t.(j = Va:K.a' 

Aha 
Ah a = a 

A h a' = a 
A h a = a' 

A h a = a 1 Ah a' — a" 

Ah a = a" 



B.3 Term Formation 




A; F h i : int 



A b Ci : « 

A I C — ► 12 — ^ 12 — ^ K — ^ K — ^ K 

A b Typerec pr [K,](int) (c;,c_>.) = C; : k 

A b ci : 12 A b C 2 : 12 A b Cj : ft 
A I C — ► I 12 — i* 12 — ^ K — ^ K — ^ K 

A b Typerec pr [K\(a -> c 2 ) (c;, c_») = 
c_> ci c 2 (Tfyperec pr [«]ci (c;,c-,.)) 
(7A/perec pr [K]c2 (c i; c^)) : k 

Ah c = c' : fi 
A b Ci = c' : K 

A b c — ► = c ^ i 12 — ^ 12 — ^ k — y k — y k 

A b Typerec pr [ft] c (c;, c_>) = 
Typerec pr [k] c' (c',c'_>) : k 



T(a;) = a 
A; r b x : a 

A; r, x:a 2 h e : a\ 

A; F b a 2 x $1 Dom(r) 
A\F h \x\ 02 .e : a 2 —y ai 
A; T b ei : (72 — >■ (7i A; _T b e2 : (72 
A;fb eie 2 : < 7 i 
A; f b e : Moc.K.a A; F h c : k 
A\ F h e[c] : cr[c/a] 

A; r, b e : a x 0 Dom(F) 
A;fb /lax.e : Vaift.cr 
A; /’ b e : (72 A; T b ui = 02 
A; ! b e : ci 



A: / • I!. : JJ(mt) 
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A-,rbIU :\/a:f 2 .V( 3 :{ 2 . 

R{ot) — > R{(3) R{o — > (3) 

A-,r\- c: n n 

A: I ■ e: 

A; F b ei : T{c(int )) 

Zi; F h e_> : Va:12.V/3:12. R{a) ->■ R{(3) 
->• T(c(a) ->• c(/3) ->• c(/3 -»• 7 )) 

Zi;F h typerec pr [c] e e; e_» : F(ct) 



C Static Semantics of AC/ 

C.l Kind Formation 



Fh K 



F,x h X 
Bhfi 

F b Ki F h k 2 
F I - Avl — ^ K,2 
E, x h « 

F h Vx-k 

C.2 Constructor Equivalence 



F; d h c = c ; : K 



F; A q:k/ h Ci : K 

E; A \~ C2 '■ k 1 
a 0 Dom(A) 

F; Zi I- (Aa:/t'.ci)c2 = ci[c 2 /a] : k 

F;Zi h c : ki -> k 2 q 0 Dom(A) 
E;A\~ Xa-.Ki.ca = c : Ki — > k 2 

F; Zi, ock h c = / : s’ 

F; Zi h Acc.k.c = A a:K.c' : k — > k! 

F; Zi I - ci == Ci 1 k — ^ k 
F; Zi h c 2 = c 2 : k/ 

F; Zi I- cic 2 = c'ic 2 : k 
E,X;Ahc: K 

F; A \- zfX-cM = c[k/x] ■ «'[«/x] 



F; Zi h c : Vx'.k 
F;Z 1 h zlx-c[x] = c : Vx'-k 

F,x;iihc = c':K 
F; zi h Zlx-c = Zlx-c' : Vx-K 

F; Zi h c = c' : Vx-ft 
F; Zi h c[k] = c'[ft] : k'[k/x] 

F; Zi I Cl — — Ci K> — ^ K 
F; Zi h c 2 = c 2 : k' 

F; zi I ci — ^ c 2 — Ci — ^ c 2 1 12 

F; Zi, a:« h a = a' 

F; Zi h \/a:K.a = VocK.a' 

E\ A \~ c : k 
E; A \~ c = c : k 

E-, A \~ c' = c : k 
E- A \~ c = c' : k 

E; A \~ c = c' : k E; A \- c' = c” : k 
F; Zi h c = c" : k 

C.3 Term Formation 

zi;F h e : cr 

Zi; F I- i : inf 

F(x) = <7 
Zi; F h a; : a 

Zi; r, x\(J2 h e : a\ 

Zi; F h cr 2 x Dom(r) 

Zi; r h \x\U2-e : cr 2 — > ai 
Zi; F h ei : ct 2 — >■ ci Zi; f h e 2 : cr 2 
Zi; F h eie 2 : o\ 

Zi; F h e : \/a:n.cr Zi; F h c : k 
Zi; F h e[c] : u[c/a] 

Zi; F, h e : a x 0 Dom(E) 

Zi; F h yla:/t.e : Vacft.cr 
Zi; F h e : a 2 ■; Zi h cti = cr 2 : 1? 

Zi; F h e : ai 
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Abstract. Many functions on context-free languages can be expressed 
in the form of the least fixed point of a function whose definition mimics 
the grammar of the given language. This paper presents the basic theory 
that explains when a function on a context-free language can be defined 
in this way. The contributions are: a novel definition of a regular algebra 
capturing division properties, several theorems showing how complex 
regular algebras are built from simpler ones, and the application of fixed 
point theory and Galois connections to practical programming problems. 



1 Introduction 

A common technique for solving programming problems is to express the prob- 
lem in terms of solving a system of mutually recursive equations. Having done so, 
a number of techniques can be used for solving the equations, ranging from sim- 
ple iterative techniques to more sophisticated but more specialised elimination 
techniques. 

A relatively straightforward and well-known example is the problem of finding 
shortest paths through a graph. The distances to any one node from the nodes 
in a graph can be expressed as a set of simultaneous equations, which equations 
can be solved using for example Dijkstra’s shortest path algorithm |DTPj. An- 
other, similar but much less straightforward, problem is that of finding the edit 
distance between a word and a (context-free) language — the minimum num- 
ber of edit operations required to edit the given word into a word in the given 
language. In the case that the language is defined by a context-free grammar, 
the problem can be solved by constructing a system of equations in the edit 
distances between each segment of the given word and each nonterminal in the 
given grammar pn»72| . This set of equations can then be solved using a simple 
iterative technique or Knuth’s generalisation of Dijkstra’s shortest path 

algorithm. 

A stumbling block for the use of recursive equations is that there is often a 
very big leap from a problem’s specification to the algorithm for constructing the 
system of simultaneous equations; the justification for the leap almost invariably 
involves a post hoc verification of the construction. Thus, whereas methods for 
solving the equations, once constructed, are well-known and understood, the 
process of constructing the equations is not. The example of edit distances just 
given is a good example. Indeed, the theory of context-free languages offers 
many examples j.lS94ll.lR95] determining whether the language generated by 



D. Sands (Ed.): ESOP 2001, LNCS 2028, pp. 1 07- 17711 2001. 
(c) Springer- Verlag Berlin Heidelberg 2001 



108 



R. Backhouse 



a given grammar is empty or not, determining the length of a shortest word in a 
context-free language, determining the FIRST set of each of the nonterminals 
in a grammar, and so on. 

In this paper we present a general theorem which expresses when the solution 
to a problem can be expressed as solving a system of simultaneous equations. We 
give several examples of the theorem together with several non-examples (that 
is, examples where the theorem is not directly applicable). The non-examples 
serve two functions. They highlight the gap between specification and recursive 
equations — we show in several cases how a small change in the specification 
leads to a breakdown in the solution by recursive equations — and they inform 
the development of a methodology for the construction of recursive equations. 

Section 0 summarises the mathematical theory underlying this paper - the 
theory of Galois connections and fixed point calculus. The novel contribution 
begins in section 0 We propose a novel definition of a regular algebra, chosen 
so that we can encompass within one theorem many examples of programming 
problems, including ones involving computations on context-free grammars as 
well as the standard examples on finite graphs. Several theorems are presented 
showing how complex regular algebras can be constructed from simpler ones. 
Section 0 introduces the notion of a regular homomorphism and specialises the 
fusion theorem of section 0 in the context of regular algebras. Section 0is about 
extending “measures” on the elements of a monoid to measures on the elements 
of a regular algebra. A measure is some function that imposes a (possibly partial) 
ordering on the elements of its domain. In order to apply the fusion theorem of 
section 0 we require that measures preserve the regular algebra structure. The 
main theorem in section 0 provides a simple test for when this is indeed the 
case for the proposed extension mechanism. The section is concluded by several 
non-trivial examples of measures on languages. 

For space reasons, proofs, further examples and extensive references have 
been omitted; see http://www.cs.nott.ac.uk/~rcb/papers instead. 

2 Galois Connections and Fixed Points 

This section summarises the (standard) mathematical theory needed to under- 
stand the later sections. The notation we use follows the recommendations of 
Dijkstra and Scholten fl )Sbl)| . In particular, angle brackets delimit the scope of 
bound variables so that (x:R:E) denotes the function that maps a value x in 
the range given by predicate R to the value denoted by expression E . Also, 
function application is denoted by an infix dot. 

2.1 Galois Connections and Fixed Points 

Definition 1 (Galois Connection). Suppose A=(A,Q) and B = (B,<) 
are partially ordered sets and suppose F £ A^B and G £ B<—A . Then (F , G ) 
is a Galois connection between A and B iff, for all x£B and y£A , 

F.x C y = x A G.y . 

We refer to F as the lower adjoint and to G as the upper adjoint. 
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The concept of a Galois connection was introduced by Oystein Ore in 1944 
and was first used in computing science in 1964 jHS64 i| . The concept 
is now widely known particularly in the field of abstract interpretation I7T771 
irm . Elementary examples of functions having Galois adjoints include negation 
of boolean values, the floor and ceiling functions, the maximum and minimum 
operators on sets of numbers, and weakest liberal preconditions. 

We assume familiarity with the notion of supremum and infimum of a (mono- 
tonic) function. Following the tradition in regular algebra to denote binary 
suprema by the symbol we use Ef to denote the supremum of / . 

The following existence theorem is often used to determine that a function 
is indeed a lower adjoint. 

Theorem 1 (Fundamental Theorem). Suppose that B is a poset and A 
is a complete poset. Then a monotonic function F G A<—B is a lower adjoint in 
a Galois connection equivales F is supremum-preserving. 

The next theorem on Galois connections is described by Lambek and Scott 
[ LS86i | as “the most interesting consequence of a Galois correspondence” . 

Theorem 2 (Unity of Opposites). Suppose FgA-^B and GgB^A are 
Galois connected functions, F being the lower adjoint and G being the upper 
adjoint. Then F.B and G.A are isomorphic posets. Moreover, if one of A or 
B is complete then F.B and G.A are also complete. 

Suppose A = ( A , C) is a partially ordered set. Assuming A is complete, we 
denote the least prefix point of / by nf . 

Theorem 3 ( /x -fusion). Suppose is the lower adjoint in a Galois 

connection between the complete posets (A , C) and (B , A) . Suppose also that 
gG(B , A) -s— (B , A) and h£(A, C) -s— (A , C) are monotonic functions. Then 

fA9 = gh <= f°g = hof . 

We call this theorem /x - “fusion” because it states when application of func- 
tion, / , can be “fused” with a fixed point, )ig , to form a fixed point, /x/i . The 
fusion rule is the basis of so-called “loop fusion” techniques in programming: the 
combination of two loops, one executed after the other, into a single loop. The 
theorem also plays a central role in the abstract interpretation of programs — 
see gDzailZa- 

2.2 Applying Fusion: Example and Non-example 

This section discusses two related examples. The first is an example of how the 
fusion theorem is applied; the second illustrates how the fusion theorem need not 
be directly applicable. Later we return to the second example and show how it 
can be generalised in such a way that the fusion theorem does become applicable. 

Both examples are concerned with membership of a set. So, let us consider 
an arbitrary set U . For each x in U the predicate ( xG ) maps a subset P 
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of U to the boolean value true if x is an element of P and otherwise to 
false . The predicate ( xG ) preserves set union. That is, for all bags S of subsets 
of U , x£UiS = 3(P: PgS: xGP) . According to the fundamental theorem, the 
predicate ( xG ) thus has an upper adjoint. Indeed, we have, for all booleans b, 

x£S=>b = S' C if 6 — > 14 0 -<b — > W\{x} fi . 

Now suppose / is a monotonic function on sets. Let /i/ denote its least fixed 
point. The fact that ( xG ) is a lower adjoint means that we may be able to apply 
the fusion theorem to reduce a test for membership in gf to solving a recursive 
equation. Specifically 

(xGgf = gg) 4= V(S:: x G f.S = g.(xGS)) . 

That is, the recursive equation with underlying endofunction / is replaced by 
the equation with underlying endofunction g (mapping booleans to booleans) 
if we can establish the property V(S:: xG f.S = g.(xGS)). An example of 
where this is always possible is testing whether the empty word is in the language 
defined by a context-free grammar. For concreteness, consider the grammar with 
just one nonterminal S and productions 

S ::= aS \ SS \ e 

Then the function / maps set X to {a}-X U X-X U {e} and the function g 
maps boolean b to (e G {a} A b) V (b A b) V e G {e} . Note how the definition of 
g has the same structure as the definition of / . Effectively set union has been 
replaced by disjunction and concatenation has been replaced by conjunction. Of 
course, g can be simplified further (to the constant function true ) but that 
would miss the point of the example. 

Now suppose that instead of taking x to be the empty word we consider any 
word other than the empty word. Then, the use of the fusion theorem breaks 
down. This is because the empty word is the only word x that satisfies the 
property x G X-Y = xGX A xGY for all X and Y . Indeed, taking x to be 
a for illustration purposes, we have 

a G n{X:: {a}-X U X X U {e}) = true , but 

g,(b:: (a£{a} A b) V (6 A b) V ae{e}) = false . 

This second example emphasises that the conclusion of g -fusion demands 
two properties of / , g and h , namely that / be a lower adjoint, and that 
f°g = h°f . The rule is nevertheless very versatile since being a lower adjoint is far 
from being uncommon, and many algebraic properties take the form f°g = h°f 
for some functions / , g and h . In cases when the rule is not immediately 
applicable we have to seek generalisations of / and/or g that do satisfy both 
properties. Example 0 shows how this is done in the case of the general mem- 
bership test for context-free languages. 
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3 Regular Algebra 

In this section we propose a novel definition of a regular algebra, motivated by 
a desire to exploit to the full the calculational properties of Galois connections. 
We give several examples of regular algebras and theorems showing how more 
regular algebras can be built up from simpler algebras. 

Our view of a regular algebra is that it is the combination of a monoid (the 
algebra of composition) and a complete poset (the algebra of choice) , with an in- 
terface between the two structures. The interface is that composition distributes 
through choice in all circumstances; in other words, the product operator of the 
monoid structure admits left and right “division” or “factorisation” operators. 

Various axiomatisations of regular algebra have been given in the past, in par- 
ticular several by Conwav fCon7 1| . Conway introduced (left and right) factors in 
the context of regular languages, exploiting implicitly the fact that concatena- 
tion functions ( L - ) and (-L), for given language L , are both lower adjoints. 
Some remarkable results in his book make significant use of the existence of 
factors. However, Conway did not base any of his axiomatisations on this fact. 
Other axiomatisations (for example, Kozen [F Rozfil ] ) are too weak to encompass 
all the applications considered in this paper. 



3.1 Definition and Examples 

Our definition of a regular algebra is a combination of a monoid and a complete, 
universally distributive lattice. 

Definition 2 (Regular Algebra). Suppose A = (A 1 A) is a complete lat- 
tice. (This means that the suprema and infima of all monotonic functions exist, 
whatever the shape set.) Denote the binary supremum operator on A by © . 
Then A is said to be universally distributive if, for all a€A , the endofunction 
( ©a ) is the upper adjoint in a Galois connection of the poset A with itself. 

A regular algebra is a 5-tuple (A,©,©, A ,0,1) where 

(a) ( A , © , 1 ) is a monoid, 

(b) ( A , A > © 1 0 ) is a complete, universally distributive lattice with least 
element 0 and binary supremum operator © , 

(c) for all a£ A , the endofunctions ( a© ) and ( ©a ) are both lower adjoints in 
Galois connections between ( A , A ) and itself. 

The standard example of a complete, universally distributive lattice is a 
power set lattice — the set of subsets of a given set ordered by set inclusion. 
The main application of universal distributivity is predicting uniqueness of fixed 
points. This however will not be an issue in this paper. 

Where necessary, we use the notation ( a\ ) and ( /a ) for the upper adjoints of 
the functions ( a© ) and ( ©a ) , respectively. Thus the rules are: for all x and y , 
a©x A y = x A o\y and x©a Ay = xAy/a. The operators \ and / are called 
division operators, and we often paraphrase requirement 121(c) as product admits 
(left and right) division. 
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Example 1 (Bool). The set IB containing the boolean values true and false 
is the carrier of a regular algebra. The ordering is implication, summation is 
disjoint sum and product is conjunction. The zero of product is false and its 
unit is true . This algebra forms the basis of decision problems. Although very 
simple, we shall see in example |3| that this is not a primitive regular algebra. 



Example 2 (Min Cost Algebra). A regular algebra that occurs frequently in 
problems involving some cost function has carrier the set of all positive real 
numbers, IR- 0 , augmented with a largest element, oo . (That is, the carrier is 
R-°U {oo} .) This set forms a monoid where the product operation is defined 
by 



x®y = if x = ooV y=oo — > oo 
□ x^oo Ay^oo — > x+y 

fi 

and the unit of product is 0 . Ordering its elements by the at-least relation, where 
by definition oo>x for all x , the set forms a complete, universally distributive 
lattice. The supremum is minimum. Henceforth, we denote the minimum of x 
and y by x\y and their maximum by x\y . Moreover, the product operation 
admits division. The upper adjoint of ( ®y ) is given by 

z/y = if y = oo — >■ 0 

□ yyfooAzyfoo — > (z— y) f 0 

□ y=£oo/\z = oo — ► oo 

fi . 



Example 3 (Bottleneck Algebra). Bottleneck problems are problems with a 
max-min requirement. For example, if it is required to drive a high load under 
a number of low bridges, we want to find the maximum over all different routes 
of the minimum height bridge on the route. A regular algebra fundamental to 
bottleneck problems has carrier the set of all real numbers, augmented with 
largest and smallest values, oo and — oo respectively. The addition operator is 
maximum (so that the ordering relation is at-most) and the product operator is 
minimum. The minimum operator is easily seen to satisfy the property 

x\.y < z = x < z/y , where 

z/y = if y<z — > oo □ y>z z fi 
That is, the product operator in the algebra admits division. 
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3.2 All Solutions 

When solving optimisation problems, where we are not just interested in the 
optimum value of the cost function, but in determining some value in the domain 
of solutions that optimises the cost function, we consider an algebra of pairs, 
where the first element is the cost and the second element is a set of values that 
have that cost. An algebra of pairs is also appropriate for decision problems, 
where a simple yes/no answer is insufficient, and when two criteria for optimality 
are combined. For example, we may wish to determine among all least-cost 
solutions to a given problem, a solution that optimises some other criterion, like 
size or weight. Theorem 0] is the basis for the use of regular algebra in such 
circumstances. The theorem details the construction of an algebra of pairs in 
which the pairs are ordered lexicographically. In general, it is not possible to 
combine arbitrary regular algebras in this way; the first algebra in the pair is 
assumed to be a cost algebra, as defined below. 

Definition 3. A cost algebra is a regular algebra with the property that the 
ordering on elements is total and, for all yyf 0 , 

(x-y)/y = x/yy = x = yy\x = y\(yx) . 

It is easy to verify that the algebras of examples [I] and |2] are cost algebras. 

Theorem 4 (Cost Algebras). Suppose 1Z\ and 7?. 2 are both regular al- 
gebras. Suppose further that TZi is a cost algebra. Define the set P to be the 
set of ordered pairs (x,r) where x£lZ\, rGlZ? and x = Oi =>r = 02 . Order P 
lexicographically; specifically, let 

(x, r) ^ (y, s) = x<yV(x = yArQ s ) 

where < is the ordering in algebra IZi , C is the ordering in algebra IZ 2 , 
and ^ is the ordering in P . Define the product operation on elements of P 
coordinatewise : 

(x,r)®(y,s) = (x-y , r°s) 

the products x-y and r°s being the products in the appropriate algebra. Define 
addition by 

(x,r)®(y,s) = if x<y-+(x,r) 

□ x = y — > (x , r+s) 

□ y < x -A (y , s) 

fi . 

Then ( P , <g> , ® , ^ , (0!,0 2 ) , (1 1 , 1 . 2 ) ) is a regular algebra. 

Example 4 . Suppose we consider a network of cities connected by a number 
of roads. Each road has a certain length and along each road there is a low 
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bridge. It is required to drive a high load from one of the cities to another by an 
“optimum” route (a route being a sequence of connecting roads). 

One criterion of optimality is that we choose, among the shortest routes, a 
route that maximises the minimum height of bridge along the route. A second 
criterion of optimality is that, among the routes that maximise the minimum 
height of bridge along the route, we choose a shortest route. 

The construction of theorem0]is applicable to the first criterion of optimality. 
The elements of the algebra are ordered pairs ( distance , height ). A route with 
“cost” (d ,h) is better than a route with “cost” ( e , fc ) if d<e or d=e and 
h>k. As this is a regular algebra, it is possible to apply the standard all-pairs 
path-finding algorithm to determine, for all pairs of cities, the cost of a best 
route between the cities. 

The construction of theorem0is not applicable to the second criterion of opti- 
mality; an attempt to embed the lexicographical ordering on ( height , distance ) 
pairs in a regular algebra fails because product does not distribute through ad- 
dition and optimal routes may be composed of suboptimal parts. 



3.3 Vector Algebras 

Recursive equations typically involve several unknowns, possibly even an infinite 
set of unknowns. This situation is modelled in a straightforward and standard 
way. We consider a collection of equations in a collection of unknowns as a 
single equation in a single unknown, that unknown being a vector of values. 
And a vector is just a function with range the carrier set of a regular algebra. 
The set of functions with domain some arbitrary, fixed set and range a regular 
algebra forms a regular algebra if we extend the operators in the range algebra 
pointwise. 

Theorem 5 (Vector Algebras). Suppose A — (A , x , + , < , 0 , 1) is a reg- 
ular algebra and suppose B—(B, C) is an arbitrary poset. Then A<— B = 
(A<—B , x , + ,<, 0 , 1) is a regular algebra, where product, addition and or- 
dering are defined pointwise and 0 and 1 are the constant functions returning 
0 and 1 , respectively. 

3.4 From Monoids to Regular Algebras 

Some important examples of regular algebras are power set algebras. These are 
introduced in this section. 

Lemma 1. Every monoid can be extended to a power set regular algebra in 
the obvious way: monoid ( A , • , 1 ) is extended to a regular algebra with carrier 
set 2 a , partial ordering the subset relation, and multiplication extended to sets 
in the usual way with {1} as the unit. 

Example 5 (Bool). The simplest possible example of a monoid has carrier 
{1} . The subsets of this set are the empty set and the set itself. The power set 
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regular algebra is clearly isomorphic to the booleans. Choosing to map the empty 
set to false and {1} to true , the product operation of the regular algebra is 
conjunction, and the addition operator is disjunction. This is examplenjdiscussed 
earlier. 

Example 6. A language over alphabet T is a set of words, i.e. a subset of T* . 
The power set regular algebra constructed from the monoid ( T* , • , e ) , where 
the infix dot denotes concatention of words and e denotes the empty word, has 
carrier the set of all languages over alphabet T . 

3.5 Graph Algebras 

If regular algebra is to be applied to path-finding problems then it is vital that 
the property of being a regular algebra can be extended to graphs/matricesEl 

PEznj. 

Often, graphs are supposed to have finite dimensions. In the present circum- 
stances — the assumption of a complete lattice — there is no need to impose this 
as a requirement. Indeed if we are to include the algebra of binary relations over 
some given, possibly infinite, set in the class of regular algebras then we certainly 
should not require graphs to have finite dimension. Other applications demand 
a very general definition of a graph. In the following, a binary relation is just a 
set of pairs. 

Definition 4. Suppose r is a binary relation and suppose A is a set. A 
(labelled) graph of dimension r over A is a function / with domain r and 
range A . Elements of relation r are called edges. 

We will use M r A to denote the class of all labelled graphs of dimension r 
over A . If / is a graph and the pair (i. j) is an element of r , then i(f)j will 
be used to denote the application of / to the pair (i, j) . 

Definition 5 (Addition and Product). Suppose lZ=(A,x , + ,<,0,1) 
is a regular algebra. Then zero and the addition and product operators of 1Z 
can be extended to graphs as follows. Two graphs / and g of the same di- 
mension r can be ordered according to the rule: for all pairs ( i,j ) in r, 
/ < g = \/(i,j:: i(f)j < i(g)j ) ■ The supremum ordering is just pointwise. In 
particular, / and g of the same dimension r are added according to the rule: 
for all pairs (i,j) in r, i{f+g)j = i(f)j + i{g)j ■ Two graphs / and g of di- 
mensions r and s can be multiplied to form a graph of dimension r°s according 
to the rule: for all pairs (i. j) in r°s , 

i(fxg)j = £(k: (i,k)€r A (. k,j)€s : i(f)k x k(g)j) . 

Finally, the zero graph, denoted by 0 , is defined by: for all pairs (i,j) in r, 

i(0)j = 0 ■ 

1 For us, the words graph and matrix are interchangeable. In some applications 
“graph” is the word that is traditionally used, in others “matrix” is more conven- 
tional. For consistency we use “graph” everywhere throughout this paper. 



116 



R. Backhouse 



Henceforth, we use M r A to denote the class of all graphs of dimension r 
over A . 

Theorem 6 (Graph Algebras). Suppose 7Z = {A , x , + , < , 0 , 1) is a reg- 
ular algebra with carrier A , and suppose r is a reflexive, transitive relation. 
Define an ordering, addition and product operators as in definition Q Define the 
unit graph, denoted by 1 , by 

i(l)j = if i = j — > 1 □ i^j — > 0 fi . 

(Note that M r A is closed under the product operation and contains 1 on 
account of the assumptions that r is transitive and reflexive, respectively.) Then 
the algebra M r lZ = ( M r A , x , + , < , 0 , 1) so defined is a regular algebra. 

There are several important examples of graph regular algebras. The binary 
relations on some set A is one example. The underlying regular algebra is the 
booleans IB , and the edge relation is the cartesian product A x A . The relation 
represented by graph / is the set of pairs (i,k) such that i(f) k . Graph addition 
corresponds to the union of relations, and graph product corresponds to the 
composition of relations. The divisions f/g and f\g are called residuals EM 
in the mathematics literature and weakest pre and post specifications [JjH8j3] in 
the computing science literature. 

Path problems on finite graphs provide additional examples of graph algebras. 
The standard example is shortest paths: the underlying algebra is the minimum 
cost algebra introduced in definition 0 

4 Regular Homomorphisms and the Main Theorem 

In this section we specialise the fusion theorem of section Q to systems of equa- 
tions with the structure of a context-free grammar. 

Definition 6 (Regular Homomorphism). Let 7Z = (R,°,1r) and S = 
(S,-,ls) be monoids. Suppose m is a function with domain R and range S. 
Then m is said to be compositional if m.(x-y) = m.x°m.y , for all x and 
y in R . Also, m is said to be a monoid homomorphism from 1Z to S if m 
is compositional and preserves units: m.l# = Is. Now let 7 Z = {R,°, ® , A 
, 0_r,1_r) and S = (S,-, + , < , Os , Is) be regular algebras. Suppose m 
is a function with domain R and range S . Then m is said to be a regular 
homomorphism if m is a monoid homomorphism (from ( i? , ° , 1# ) to ( S , ■ , 1 <j )) 
and it is a lower adjoint in a Galois connection between the two orderings. 

For m to be a regular homomorphism it must be compositional and pre- 
serve the unit of 1Z . However, the latter requirement is redundant if we re- 
strict attention to the values in the image of R under to . After all, we have 
m.x = m.(xolfi) = m.x-mAfi and, similarly, m.y = m.(ln°y) = mAji-m.y 
so that ( m.R , • ,to.1a ) is a monoid, where m.R denotes the image of the set 
R under to . In more complicated applications this observation becomes impor- 
tant. Formally, we combine the observation with the unity-of-opposites theorem 
in the following theorem. 
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Theorem 7 (Range Algebras). Let R = (R , ° , © , < ,0rAr) and <5 
= (S Os , Is) be regular algebras. Suppose to is a function with 

domain R and range S that is compositional and is a lower adjoint in a Galois 
connection between the orderings. Let m.R be the image of R under to and 
let rrfi denote its upper adjoint. Then m.R = ( m.R , • , EH , < , Os , m.lR) 
is a regular algebra, where a’EHy = m.(mKx © m^.y) . Moreover, to is a regular 
homomorphism from R to m.R . 

Regular homomorphisms are lower adjoints and are compositional. These 
are exactly the conditions we need to apply the fusion theorem to systems of 
equations with the structure of a context-free grammar. 

Theorem 8 (Fusion on Languages). Suppose G is a context-free gram- 
mar, and R and S are regular algebras. Suppose also that to is a regular 
homomorphism from R to S . Suppose g is the endofunction obtained in the 
obvious way from G by interpreting concatenation and choice by the product 
and addition operators of R , and by giving suitable interpretations to the sym- 
bols of the alphabet. Suppose h is obtained in the same way using S instead 
of R . (See section 12^1 for an example.) Then m . pg = ph . 

5 Measures 

On its own, theorem 0 is difficult to use because the requirement of being a 
regular homomorphism is quite strong. However, the sort of functions m that 
we usually consider are defined by extending a function on words to a function 
on languages. We call such functions “measures”. The sort of measures we have 
in mind are the length of a word, the first k symbols in a word, and the edit 
distance of a word from some given word. For example the length function on 
words is extended to the length-of-a-shortest-word function on languages. 

In this section we show that the standard mechanism for extending a mea- 
sure to a set results in a homomorphism of regular algebras, the only condition 
being that we start with a measure that is compositional. This makes theorem 
0 relatively easy to use. 

Theorem 9 (Monoidal Extensions) . Suppose that ( M , • , 1 m ) is a monoid 
and that R = (!?,•,+ , < , 0# , 1#) is a regular algebra. Suppose to is a 
function with domain M and range R . Consider the power set algebra ( 2 M , • , U 
, C , cj) , {1a/} ) as defined in theorem El Define measure , the extension of 
to to subsets of M (elements of 2 M ), by measure. S = £(x: xGS: m.x) . Then 
measure is a regular homomorphism if m is compositional. 

We consider several examples. 

Example 1 (Test for Empty). Suppose we wish to determine whether a lan- 
guage is empty or not. Consider the regular algebra IB (definition©. Define 
the measure to of a word to be true . Then the extension measure of to to 
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sets of words tests whether a language is empty or not. Specifically, by defini- 
tion measure. S = 3(u: uGS: true) . That is, measure. S = S^<f>. The measure 
m is clearly compositional and so measure is a regular homomorphism, and 
theorem 0 can be applied. 

Example 8 (Membership) . We return to the membership problem discussed 

in section |S1 Consider the regular algebra IB (definition 0). Given a word X , 
define the measure m of a word u to be u = X . Then the extension, measure, 
of to to sets of words tests for membership of x in the set. Specifically, by 
definition measure. S = 3(u: uGS: u = X) . That is, measure. S = XgS . This 
measure is a regular homomorphism if measure to is compositional. But to is 
compositional equivales £ = X . So the only example of a membership test on 
sets of words that is a regular homomorphism is the so-called nullability test: 
the test whether the empty word is in the set. So only in this case can theorem 
0be applied directly. 

The next two examples involve graph algebras. Note how example 0 gener- 
alises example 0 

Example 9 (General Context-Free Parsing). The general parsing algorithm 
invented by Cocke, Younger and Kasami exploits a regular homomorphism. (See 
[IA 1 1 7‘il P 332] for references to the origin of the Cocke-Younger-Kasami parsing 
algorithm.) 

Let X be a given word and let N be the length of X . The motivating 
problem is to determine whether X — the input string — is in a language L 
given by some context-free grammar. 

We use X to define a measure on words and then we extend the measure to 
sets and then to vectors of sets. The measure of word u is a graph of Booleans 
that determines which segments of X are equal to u . Specifically, let us index 
the symbols of X from 0 onwards. The edge relation of the graph is the set of 
pairs (i ,j ) such that 0 < i < j < N and will be denoted by seg . Note that this 
is a reflexive, transitive relation. For brevity we omit this constraint on i and 
j from now on. 

Now, with i and j satisfying 0 < * < j < N , let X [ i . . j ) denote the segment 
of word X beginning at index i and ending at index j— 1 . (So X[i ..i) is the 
empty word.) Now define^ m.u = (*,j:: X[i..j) = u) . This defines m.u to be 
a boolean graph with dimension the set of pairs {i , j ) satisfying 0 <i<j<N. 
The extension of the measure to to sets is 

measure. S = (i, j:: 3(u: uGS: X[i..j) = u)) 

so that 

0 (measure. S)N = XgS . 

Crucial to the correctness of the Cocke-Younger-Kasami algorithm is that to is 
compositiona l. This is proved as follows. 

2 Recall that ( i , j:: X [i .. j ) =u) denotes a function mapping pair ( i , j ) (implicitly) 
satisfying 0 < i < j < N to the boolean value X [ i .. j ) = u . 
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m.u x m.v 

= { definition of m } 

( i,j ■■ X[i..j)=u)x ( i,j :: X[i..j)=v) 

= { definition of graph product in algebra M seg IB } 

(i, j:: 3 (k:: X [i .. k) = u A X [k .. j) =v)) 

= { word calculus } 

X [i .. j) =u-v) 

= { definition of to } 

m.(u-v ) . 

We conclude that theorem 0 can be applied. Thus testing 
element of the language generated by a context-free grammar 
a system of order N 2 x k equations where k is the number 
the grammar. 

The final example is the most complicated, and requires a more complicated 
justification. 

Example 10 (Error Repair). A general technique for error repair when parsing 
languages is to compute the minimum number of edit operations required to 
edit the input string into a string in the language being recognised EF72I . 
The technique involves a generalisation of the Cocke- Younger-Kasami algorithm, 
similar to the generalisation that is made when going from Warshall’s transitive 
closure algorithm to Floyd’s all-shortest-paths algorithm. 

Let A be a given word (the input string) and let N be the length of X . As 
in example 0 we use X to define a measure on words and then we extend the 
measure to sets. The measure of word u is a triangular graph of numbers that 
determines how many edit operations are required to transform each segment of 
X to the word u . 

Transforming one word to another involves a sequence of primitive edit op- 
erations. Initially the input index, i , is set to 0 ; the edit operations scan the 
input string from left to right, transforming it to the output string. The allowed 
edit operations and their effect on the input string are 

— Insert(a) . Insert symbol a after the current symbol in the output string. 

— Delete . Increment the index i . 

— ChangeTo{a) . Increment the index i and add symbol a to the end of the 
output string. 

— OK . Copy the symbol at index i of the input to the output. Then increment 

i . 

(We will see that the choice of allowed edit operations is crucial to the correctness 
of the generalised algorithm.) 



whether X is an 
G involves solving 
of nonterminals in 
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Let dist{u,v ) denote the minimum number of non-OK edit operations needed 
to transform word u into word v using a sequence of the above edit operations. 
Now define 

m.u = (i, j:: dist(X[i..j) ,u)} . 

This defines m.u to be a graph of numbers. The numbers, augmented by oo , 
form the min-cost regular algebra discussed in example 0 Thus graphs over num- 
bers also form a regular algebra. Taking this as the range algebra, the extension 
of the measure m to sets is 

measure. S = (i,jr. i (u:uGS: dist(X[i..j) ,u))) 

so that 0 (measure. S)N is the minimum number of edit operations required to 
repair the word X to a word in S . 

Crucial to the correctness of the generalised Cocke- Younger-Kasami algo- 
rithm is that to is compositional. This follows from 

dist(X[i..j) , u-v) = 4- (k-. dist(X[i..k) ,u) + dist(X[k..j) ,v)} 

which is a non-trivial property of the chosen collection of edit operations 

To see that the property is non-trivial, suppose we extend the set of edit 
operations to allow the transposition of two adjacent characters. (Transposing 
characters is a very common error when using a keyboard.) Then the edit dis- 
tance function is not compositional as, for example, dist (“ab”,“ba”) is 1 — it 
takes one transposition to transform the word “ab” to the word “ba”- but this is 
not equal to the minimum of dist (“ab”,“b”) + dist{e ,“a”) and dist (“a”, “b”) 
+ dist ( “b” , “a” ) and dist(e , “b” ) + dist ( “ab” , “a” ) — which it should be if the 
function to were to be compositional. Indeed, computing minimal edit distances 
for context-free languages is very difficult if the possibility of transpositions is 
included in the analysis. 

This is the first example where to is compositional but not a monoid ho- 
momorphism. In an algebra of graphs with underlying algebra minimum costs 
the ( i,j )th entry in the unit graph is oo whenever i^j. The ( i,j )th entry in 
TO.e , on the other hand, is the cost of deleting all the symbols of X [ i .. j ). This 
is an instance where theorem Q is really needed. The extension measure of to 
is indeed a regular homomorphism; its domain is the algebra over languages and 
its range is the algebra of graphs in the image set of measure . 
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Abstract. Many modern programs provide operating system-style ser- 
vices to extension modules. A Web server, for instance, behaves like a 
simple OS kernel. It invokes programs that dynamically generate Web 
pages and manages their resource consumption. Most Web servers, how- 
ever, rely on conventional operating systems to provide these services. 
As a result, the solutions are inefficient, and impose a serious overhead 
on the programmer of dynamic extensions. 

In this paper, we show that a Web server implemented in a suitably ex- 
tended high-level programming language overcomes all these problems. 
First, building a server in such a language is straightforward. Second, 
the server delivers static content at performance levels comparable to a 
conventional server. Third, the Web server delivers dynamic content at 
a much higher rate than a conventional server, which is important be- 
cause a significant portion of Web content is now dynamically generated. 
Finally, the server provides programming mechanisms for the dynamic 
generation of Web content that are difficult to support in a conventional 
server architecture. 



1 Web Servers and High-Level Operating Systems 

A Web server provides operating system-style services. Like an operating system, 
a server runs programs (e.g., CGI scripts). Like an operating system, a server 
protects these programs from each other. And, like an operating system, a server 
manages resources (e.g., network connections) for the programs it runs. 

Some existing Web servers rely on the underlying operating system to im- 
plement these services. Others fail to provide services due to shortcomings of 
the implementation languages. In this paper, we show that implementing a Web 
server in a suitably extended functional programming language is straightfor- 
ward and satisfies three major properties. First, the server delivers static con- 
tent at a performance level comparable to a conventional server. Second, the Web 
server delivers dynamic content at five times the rate of a conventional server. 
Considering the explosive growth of dynamically created Web pages [Zj, this 
performance improvement is important. Finally, our server provides program- 
ming mechanisms for the dynamic generation of Web content that are difficult 
to support in a conventional server architecture. 

D. Sands (Ed.): ESOP 2001, LNCS 2028, pp. 122- fHBl 2001. 

(c) Springer- Verlag Berlin Heidelberg 2001 
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The basis of our experiment is Mr Ed JH], an extension of Scheme jEj. The 
implementation of the server heavily exploits four extensions: first-class mod- 
ules, which help structure the server and represent server programs; preemptive 
threads; which are needed to execute server programs; custodians, which man- 
age the resource consumption of server programs; and parameters, which control 
stateful attributes of threads. The server programs also rely on Scheme’s ca- 
pabilities for manipulating continuations as first-class values. The paper shows 
which role each construct plays in the construction of the server. 

The following section is a brief introduction to Mr Ed. Section 0 explains the 
core of our server implementation. In section 0we show how the server can be 
extended to support Scheme CGI scripts and illustrate how programming in the 
extended Scheme language facilitates the implementation of scripts. Sections 0 
and 0 also present performance results. Section 0 discusses related work. The 
final section summarizes our ideas and presents areas for future work. 

2 MrEd: A High-Level Operating System 

MrEd HO is a safe implementation of Scheme HO; it is one of the fastest existing 
Scheme interpreters. Following the tradition of functional languages, a Scheme 
program specifies a computation in terms of values and legitimate primitive 
operations on values (creation, selection, mutation, predicative tests). The im- 
plementation of the server exploits traditional functional language features, such 
as closures and standard data structures, and also Scheme’s ability to capture 
and restore continuations, possibly multiple times. 

MrEd extends Scheme with structures, exceptions, and modules. The module 
system m permits programmers to specify atomic units and compound units. 
An atomic unit is a closed collection of definitions. Each unit has an import and 
an export signature. The import signature specifies what names the module ex- 
pects as imports; the export signature specifies which of the locally defined names 
will become visible to the rest of the world. Units are first-class values. There 
are two operations on unit values: invocation and linking. A unit is invoked via 
the invoke-unit/sig special form, which must supply the relevant imports from 
the lexical scope. MrEd permits units to be loaded and invoked at run-time. A 
unit is linked — or compounded — via the compound-unit/sig mechanism. Pro- 
grammers compound units by specifying a (possibly cyclic) graph of connections 
among units, including references to the import signature; the result is a unit. 

The extended language also supports the creation of threads and thread 
synchronization. Figure 0 specifies the relevant primitives. Threads are created 
from 0-ary procedures (thunks); they synchronize via counting semaphores. For 
communication between parent and child threads, however, synchronization via 
semaphores is too complex. For this purpose, MrEd provides (thread) parame- 
ters. The form 

(parameterize ([parameter 1 value 1]...) body 1...) 

sets parameterl to valuel for the dynamic extent of the computation bodyl 
...; when this computation ends, the parameter is reset to its original value. New 
threads inherit copies of their parent’s parameter bindings, though the parame- 
ter values themselves are not copied. That is, when a child sets a parameter, it 
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tcp-listen : Nat [Nat] — t Tcp-listener 

;; reserves a port to accept connections, optionally specifying the 
;; maximum number of clients that may wait for a connection 

tcp-accept : Tcp-listener —¥* Input-port Output-port 

;; creates I/O ports for a connection request via the listener 



thread : (— > Void) — > Thread 
;; spawns a thunk as a thread 

make-semaphore : Nat — t Semaphore 

;; creates a semaphore with specified number of tokens 

semaphore-post : Semaphore — >■ Void 

;; posts a semaphore and releases waiting threads 

semaphore-wait : Semaphore — > Void 

;; waits (and possibly suspends) for a semaphore 

make- custodian : -4 Custodian 
;; creates a custodian 

custodian- shutdown- all : Custodian -4 Void 

;; shuts down all threads in custodian and reclaims all resources 



Fig. 1. MrEd’s TCP, thread and custodian primitives 



does not affect a parent; when it mutates the state of a parameter, the change 
is globally visible. The server deals with only two of MrEd’s standard parame- 
ters: current- custodian and exit-handler. The default exit-handler halts the entire 
runtime system. Setting this parameter to another function can cause conditions 
that would normally exit to raise an exception or perform clean up operations. 

Finally, MrEd provides a mechanism for managing resources, such as threads 
(with associated parameter bindings), TCP listeners, file ports, and so on. When 
a resource is allocated, it is placed in the care of the current custodian , the value 
of the current- custodian parameter. Figure Q specifies the only relevant opera- 
tion on custodians: custodian-shutdown-all. It accepts a custodian and reaps the 
associated resources: it kills the threads in its custody, closes the ports, reclaims 
the TCP listeners, and recursively shuts down all child custodians. 



3 Serving Static Content 

A basic web server satisfies HTTP requests by reading Web pages from files. 
High-level languages ease the implementation of such a server, while retaining 
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efficiency comparable to widely used servers. The first subsection explains the 
core of our server implementation. The second subsection compares performance 
figures of our server to Apache |2j, a widely-used, commercially-deployed server. 



3.1 Implementation of the Web Server’s Core 

The core of a web server is a wait-serve loop. It waits for requests on a particular 
TCP port. For each request, it creates a thread that serves the request. Then 
the server recurs Q 

;; server-loop : Tcp-listener -» Void 
(define ( server-loop listener ) 

(let-values ([{ip op) ( tcp-accept listener)]) 

( thread (lambda () ( serve-connection ip op)))) 

( server-loop listener)) 

For each request, the server parses the first line and the optional headers: 

;; serve-connection : Input-port Output-port — > Void 
(define ( serve-connection ip op) 

(let-values ([( meth url-string major-version minor-version) 

( read-request ip opj\) 

(let* ([ headers ( read-headers ip op)] 

[url (string— turl url-string )] 

[host ( find-host. ( url-host url) headers)]) 

( dispatch meth host port url headers ip op)))) 

;; read-request : Input-port Output-port -t* Symbol String String String 

;; to read a request from ip, to parse it, and to determine the 
;; request method (get, put), URL, and protocol versions 
;; effect : raises an exception and closes the ports, if parsing fails 
(define ( read-request ip op) ...) 

A dispatcher uses this information to find the correct file corresponding to 
the given URL. If it can find and open the file, the dispatcher writes the file’s 
contents to the output port; otherwise it writes an error message. In either case, 
it closes the ports before returning^ 



3.2 Performance 

It is easy to write compact implementations of systems with high-level con- 
structs, but we must demonstrate that we don’t sacrifice performance for ab- 
straction. More precisely, we would like our server to serve content from files 
at about the same rate as Apache JJ- We believed that this goal was within 

1 let-values binds names to the values returned by multiple- valued computations such 
as tcp-accept , which returns input and output ports. 

2 The server may actually loop to handle multiple requests per connection. Our paper 
does not explore this possibility further. 
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The client and server software each ran on an AMD Athlon 800MHz processor 
with 192 Mbytes of memory, running FreeBSD 4.1.1-STABLE, connected by 
a standard 100 Mbit/s Ethernet connection. 



Fig. 2. Performance for static content server 



reach because most of the computational work involves parsing HTTP requests, 
reading data from disk, and copying bytes to a (network) port.0 

To verify this conjecture, we compared our server’s performance to that of 
Apache on files of three different sizes. For each test, the client requested a 
single file repeatedly. This minimized the impact of disk speed; the underlying 
buffer cache should keep small files in memory. Requests for different files would 
even out the performance numbers according to Amdahl’s law because the total 
response time would include an extra disk access component that would be 
similar for both servers. 

The results in figure |5| show that we have essentially achieved our goal. The 
results were obtained using the S-client measuring technology 0. For the his- 
torically most common case [Jj — files between six and thirteen kB — our server 
performs at a rate of 60% to 80% of Apache. For larger files, which are now 
more common due to increased uses of multimedia documents, the two servers 
perform at the same rate. In particular, for one and ten kB files, more than four 
pending requests caused both servers to consume all available CPU cycles. For 
the larger 100 kB files, both servers drove the network card at full capacity. 



4 Dynamic Content Generation 

Over the past few years, the Web’s content has become increasingly dynamic. 
USA Today , for instance, finds that as of the year 2000, more than half of the 
Web’s content is generated dynamically f3j. Servers no longer retrieve plain files 

3 This assumes that the server does not have a large in-memory cache for frequently- 
accessed documents. 
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from disk but use auxiliary programs to generate a document in response to a 
request. These Web programs often interact with the user and with databases. 
This section explains how small changes to the code of section 0 accommodate 
dynamic extensions, that the performance of the revised server is superior to 
that of Apache 0 and that it supports a new programming paradigm that is 
highly useful in the context of dynamic Web content generation. 



4.1 Simple Dynamic Content Generation 

Since a single server satisfies different requests with different content generators, 
we implement a generator as a module that is dynamically invoked and linked 
into the server context. More specifically, a CGI program in our world is a unit: 

(unit/sig () (import cgi~) ( def+exp ) ... {exp)) 

It exports nothing; it imports the names specified in the cgi" signature. The 
result of its final expression (and of the unit invocation) is an HTML page.Q 
Here is a trivial CGI program using quasiquote P2] to create an HTML 
page with unquote (a comma) allowing references to the TITLE definition. 

(unit/sig () (import cgi~) 

(define TITLE "My first web page") 

‘(html (head (title , TITLE)) 

(body 

(p (center , TITLE )) 

(p "Hello, World!")))) 

The script defines a title and produces a simple Web page containing a mes- 
sage. 

The imports of a content generator supply the request method, the URL, the 
optional headers, and the bindings: 

(define-signature cgi * ( 
method ; (union ’get ’post ’head) 

url ; Url 

headers ; (listof ( cons Symbol String)) 

bindings ; (listof ( cons Symbol String)) 

...)) 

To add dynamic content generation to our server, we modify the dispatch 
function from section 0 to redirect requests for URLs starting with “/cgi-bin/”. 
More concretely, instead of responding with the contents of a file, dispatch loads 
a unit from the specified location in the file system. Before invoking the unit, 
the function installs a new current- custodian and a new exit-handler via a pa- 
rameterize expression: 

4 Apache outperforms most other servers for CGI-based content generation PJ. 

5 To be precise, it generates an X-expression, which is an S-expression representation 
of an XML document. The server handles other media types also; we do not discuss 
these in this paper. 
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;; in dispatch : 

(if ( cgi-url ? url) 

(let ([ cust ( make- custodian )]) 

(parameterize 

{[current- custodian cust] 

[exit-handler (lambda ( x ) {custodian- shutdown- all cust))]) 

(let ([ cgi-program {cached-load { url-path url))]) 

{output-xhtml (invoke-unit/sig cgi-program cgi “))))) 

•••) 

The newly installed custodian is shut down on termination of the CGI script. 
This halts child threads, closes ports, and reaps the script’s resources. The new 
exit-handler is necessary so that erronious content generators shut down only 
the custodian instead of the entire server. 

4.2 Content Generators Are First-Class Values 

Since units are first-class values in MrEd, the server can store content generators 
in a cache. Introducing a cache avoids some I/O overhead but, more importantly, 
it introduces new programming capabilities. In particular, a content generator 
can now maintain local state across invocations. Here is an example: 

(let {[count 0]) 

(unit/sig () (import cgi") 

(set! count (addl count)) 

‘(html (head (title "Testing Persistent State of Counter")) 

(body (p "This is a cgi generated web page.") 

(p "The current count is " , (number— ^string count)))))) 

This generator maintains a local count that is incremented each time the 
unit is invoked to satisfy an HTTP request. Its output is an HTML page that 
contains the current value of count. 

4.3 Exchanging Values between Content Generators 

In addition to maintaining persistent state across invocations, content generators 
may also need to interact with each other. Conventional servers force server 
programs to communicate via the file system or other mechanisms based on 
character streams. This requires marshaling and unmarshaling data, a complex 
and error prone process. In our server architecture, dynamic content generators 
can naturally exchange high-level forms of data through the common heap. 

Our dynamic content generation model features a simple extension that per- 
mits multiple generators to be defined within a single lexical scope. The current 
unit of granularity in the implementation is a file. That is, one file may yield an 
expression that contains multiple generators. The expression may perform arbi- 
trary operations to define and initialize the shared scope. To distinguish between 
the generators, the server’s interface requires that the file return an association 
list of type 

(listof ( cons Symbol Content-generator)) 
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For instance, a file contain two content generators: 

(let* ([data- file . . .] 

[lock (make- semaphore 1)]) 

‘((add . ,(Content-generator)i) 

(delete . ,(Content-generator) 2 ))) 

This yields two generators that share a lock to a common file. The distin- 
guishing name in the association is treated as part of the URL in a CGI request. 

4.4 Interactive Generation of Content 

In a recent ICFP article m, Christian Queinnec suggested that Web brows- 
ing in the presence of dynamic Web content generation can be understood as 
the process of capturing and resuming continuations 0 For example, a user can 
bookmark a generated page that contains a form and (try to) complete it sev- 
eral times. This action corresponds to the resumption of the content generator’s 
computation after the generation of the first form. 

Ordinarily, programming this style of computation is a complex task. Each 
time the computation requires interaction (responses to queries, inspection of 
intermediate results, and so forth) from the user, the programmer must split 
the program into two fragments. The first generates the request for interaction, 
typically as a form whose processor is the remainder of the computation. The first 
program must store its intermediate results externally so the second program can 
access and use them. The staging and marshaling are cumbersome, error-prone, 
slow, and inhibit the reuse of existing non-CGI programs that are being refitted 
with Web-based interfaces. To support this common programming paradigm, 
our server links content generators to the three additional primitives in figure [3 



send/suspend : (Url -» Html-page) — » (list Method 

Url 

(listof (cons Symbol String)) 
(listof (cons Symbol String))) 

send/finish : Html-page — > Void 
adjust-timeout : Nat —¥ Void 



Fig. 3. Additional content generator primitives 



The send/suspend function allows the content generator to send an HTML 
form to the client for further input. The function captures the continuation and 
suspends the computation of the content generator. When the user responds, 
the server resumes the continuation with four values: the request method, the 
URL, the optional headers, and the form bindings. 



This idea also appears in Hughes’s paper on arrows M- 
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To implement this functionality, send/suspend consumes a function of one 
argument. This function, in turn, consumes a unique URL and generates a form 
whose action attribute refers to the URL. When the user submits the form, 
the suspended continuation is resumed. Consider figure EJ which presents a sim- 
ple example of an interactive content generator. This script implements curried 
multiplication, asking for one number with one HTML page at a time. The two 
underlined expressions represent the intermediate stops where the script displays 
a page and waits for the next set of user inputs. Once both sets of inputs are 
available it produces a page with the product. 



(unit/sig () (import cgi~) 

;; get-input-w/- short- form : String — ► (String — ► Html-page) 
(define ( get-input-w/-short-form which-one ) 

(let-values ([(method url headers bindings) 
(send/suspend 



(lambda ( k-url 



iber")) 



k-url 



)) 



‘(html (head (title , which-one " 

(body 

(form ((method "post") (action 

"Enter the " ,uihich-one " number:" nbsp 
(input ((type "text") (name .which-one))) 

(input ((type "submit") (name "submit"))))))))]) 

(extract which-one bindings))) 



;; string-multiply : String String — ► String 



‘(html (head (title "Product")) 

(body (p "The product is: " 

,( string-multiply (get-input-w /-short-form "first") 

(get-input-w/- short- form "second")))))) 



Fig. 4. An interactive CGI program 



In general, this paradigm produces programs that naturally correspond to 
the flow of information between client and server. These programs are easier 
to match to specifications, to validate, and to maintain. The paradigm also 
causes problems, however. The first problem, as Queinnec points out, concerns 
garbage collection of the suspended continuations. By invoking send/suspend , a 
content generator hands out a reference to its current continuation. Although 
these references to continuations are symbolic links in the form of unique URLs, 
they are nevertheless references to values in the server’s heap. Without further 
restrictions, garbage collection cannot be based on reachability. To make matters 
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worse, these continuations also hold on to resources, such as open files or TCP 
connections, which the server may need for other programs. 

Giving the user the flexibility to bookmark intermediate continuations and 
explore various choices creates another problem. Once the program finishes in- 
teracting with the user, it records the final outcome by updating persistent state 
on the server. These updates must happen at most once to prevent catastrophes 
such as double billing or shipping too many items. 

Based on this analysis, our server implements the following policy. When the 
content generator returns or calls the send/finish primitive, all the continuations 
associated with this generator computation are released. Generators that wish 
to keep the continuations active can suspend instead. When a user attempts to 
access a reclaimed continuation, a page directs them to restart the computation. 
Furthermore, each instance of a content generator has a predetermined lifetime 
after which continuations are disposed. Each use of a continuation updates this 
lifetime. A running continuation may also change this amount by calling adjust- 
timeout. This mechanism for shutting down the generator only works because the 
reaper and the content generator’s thread share the same custodian. This illus- 
trates why custodians, or resource management in general, cannot be identified 
with individual threads. 



4.5 Implementing Interactive Generation of Content 

The implementation of the interactive CGI policy is complicated by the (natural) 
MrEd restriction that capturing a continuation is local to a thread and that a 
continuation can only be resumed by its original thread. To comply with this 
restriction, send/suspend captures a continuation, stores it in a table indexed 
by the current content generator, and causes the thread to wait for input on a 
channel. When a new request shows up on the channel, the thread looks up the 
matching continuation in its table and resumes it with the request information 
in an appropriate manner. A typical continuation URL looks like this: 

http : //www/ cgi-bin/send-test . ss ; id38 ,k3-839800468 

This URL has two principle pieces of information for resuming computation: the 
thread (id38) and the continuation itself (k3). The random number at the end 
serves as a password preventing other users from guessing continuation URLs. 

The table for managing the continuations associated with a content generator 
actually has two tiers. The first tier associates instance identifiers for content 
generators with a channel and a continuation table. This continuation table 
associates continuation identifiers with continuations. Here is a rough sketch: 
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When a thread processes a request to resume its generator’s continuation, it looks 
up the content generator in one table, and extracts the channel and continuation 
table for that generator. The server then looks up the desired continuation in 
this second table and passes it along with the request information and the ports 
for the current connection. 

The two-tier structure of the tables also facilitates clean-up. When the time 
limit for an instance of a content generator expires or when the content generator 
computation terminates, the instance is removed from the generator instance 
table. This step, in turn, makes the continuation instance table inaccessible and 
thus available for garbage collection. 

4.6 Performance 

We expect higher performance from our Web server than from conventional 
servers that use the Common Gateway Interface (CGI) ESI- A conventional 
server starts a separate OS process for each incoming request, creating a new 
address space, loading code, etc. Our server eliminates these costs by avoiding 
the use of OS process boundaries and by caching CGI programs. 

Our experiments confirm that our server handles more connections per second 
than CGI programs written in C. For example, for the comparison in figure |5] 
we clock a C program’s binary in CGI and FastCGI against a Scheme script 
producing the same data. The table does not contain performance figures for 
responses of 100 kB and larger because for those sizes the network bandwidth 
becomes the dominant factor just as with static files. 

The table also indicates that both the standard CGI implementation and our 
server scale much better relative to response size than FastCGI does. We con- 
jecture that this is because FastCGI copies the response twice, and is thus much 
more sensitive to the response size. Of course, as computations become more 
intensive, the comparison becomes one of compilers and interpreters rather than 
of servers and their protocols. We are continuing to conduct experiments, and 
intend to present the additional performance measurements in a future edition 
of this paper. 

4.7 Modularity of the Server 

Web servers must not only be able to load web programs (e.g., CGI scripts) but 
also load new modules in order to extend their capabilities. For example, requir- 
ing password authentication to access particular URLs affects serving content 
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MrEd Full is the server described in this paper. It includes the continuation reaper 
described at the end of section 4.4, whose implementation is currently quite inefficient. 
MrEd Lite disables this reaper (rendering send/suspend less usable), making its services 
more directly comparable to those of CGI and FastCGI. 



Fig. 5. Performance for dynamic content generation 



from files and from all dynamic content generators. In order to facilitate billing 
various groups hosted by the server, the administrator may find it helpful to 
produce separate log files for each client instead of a monolithic one. A flexi- 
bly structured server will split key tasks into separate modules, which can be 
replaced at link time with alternate implementations. 

Apache’s module system [25! allows the builder of the Web server to replace 
pieces of the server’s response process, such as those outlined above, with with 
their own code. The builder installs structures with function pointers into a 
Chain of Command pattern M- Using this pattern provides the necessary ex- 
tensibility but it imposes a complex protocol on the extension programmer, and 
it fails to provide static guarantees about program composition. 

In contrast, our server is constructed in a completely modular fashion using 
the unit system m ■ This provides the flexibility of the Apache module system 
in a less ad hoc, more hierarchical manner. To replace part of how the server 
responds to requests, the server builder writes a compound unit that links the 
provided units and the replacement units together, forming an extended server. 
Naturally, the replacement units may link to the original units and delegate to 
them as desired. 

Using units instead of dynamic protocols has several benefits. First, the server 
doesn’t need to traverse chains of structures, checking for a module that wants 
to handle the request. Second, the newly linked server and all the replacement 
units are subject to the same level of static analysis as the original server. (Our 
soft-typing tool jSj revealed several easily corrected premature end-of-file bugs 
in the original server.) 

5 Related Work 

The performance problems of the CGI interface has led others to develop higher- 
speed alternatives (2QES1. In fact, one of the driving motivations behind the 
Microsoft .NET initiative f][J appears to be the need to improve Web server 
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performance, partially by eliminating process boundaries Q Apache provides a 
module interface that allows programmers to link code into the server that, 
among other things, generates content dynamically for given URLs. However, 
circumventing the underlying operating system’s protection mechanisms without 
providing an alternative within the server opens the process for catastrophic 
failures. 

FastCGI [2D] provides a safer alternative by placing each content generator 
in its own process. Unlike traditional CGI, FastCGI processes handle multiple 
requests, avoiding the process creation overhead. The use of a separate pro- 
cess, however, generates bi-directional inter-process communication cost, and 
introduces coherence problems in the presence of state. It also complicates the 
creation of CGI protocols that communicate higher-order data, such as that of 
section PI 

IO-Lite [E.. demonstrates the performance advantages to programs that are 
modified to share immutable buffers instead of copying mutable buffers across 
protection domains. Since the underlying memory model of MrEd provides safety 
and immutable string buffers, our server automatically provides this memory 
model without the need to alter programming styles or APIs. 

The problem of managing resources in long-running applications has been 
identified before in the Apache module system j2Ej . in work on resource con- 
tainers 0, and elsewhere. The Apache system provides a pool-based mechanism 
for freeing both memory and file descriptors en masse. Resource containers pro- 
vide an API for separating the ownership of resources from traditional process 
boundaries. The custodians in MrEd provide similar functionality with a simpler 
API than those mentioned. 

Like our server programs, Java servlets 0 are content generating code that 
runs in the same runtime system as the server. Passing information from one 
request to the processing of the next request cannot rely on storing information 
in instance variables since the servlet may be unloaded and re-loaded by the 
server. Passing values through static variables does not solve the problem either, 
since in some cases the server may instantiate multiple instances of the servlet 
on the same JVM or on different ones. Instead they provide session objects that 
assist the programmer with the task of manually marshaling state into and out 
of re-written urls, cookies, or secure socket layer connections. 

The Java servlet interface allows implementations to distribute requests to 
multiple JVMs for automatic load balancing purposes. Lacking the subprocess 
management facilities of MrEd’s custodians, they rely on an explicit delete 
method in the servlet to shut the subprocess down cooperatively. While this 
provides more flexibility by allowing arbitrary clean-up code, the servlet isn’t 
guaranteed to comply. 

Finally, the J-Server m runs atop Java extended with operating systems 
features. The J-Server team identified and addressed the server’s need to prevent 
dynamic content generators from shutting down the entire server, while allowing 
the server to shutdown the content generators reliably. They too identified the 
need for generators to communicate with each other, but their solution employs 

1 Jim Miller, personal communication. 
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remote method invocation (which introduces both cost and coherence concerns) 
instead of shared lexical scope. Their work addresses issues of resource accounting 
and quality of service, which is outside the scope of this paper. Their version of 
Java lacks a powerful module system and first-class continuations. 

6 Conclusion and Future Work 

The content of the Web is becoming more dynamic. The next generation of 
Web servers must therefore tightly integrate and support the construction of 
extensible and verifiable dynamic content generators. Furthermore, they must 
allow programmers to write interactive, dynamic scripts in a more natural fashion 
than engendered by current Web scripting facilities. Finally, the servers must 
themselves become more extensible and customizable. 

Our paper demonstrates that all these programming problems can be solved 
with a high-level programming language, provided it offers OS-style services 
in a safe manner. Our server accommodates both kinds of extensibility found 
in traditional servers — applications, which serve data, and extensions, which 
adapt the behavior of the server itself — by exploiting its underlying module 
system. All these features are available on the wide variety of platforms that run 
MrEd (both traditional operating systems and experimental kernels such as the 
os/Kit na). The result is a well-performing Web server that accommodates 
natural and flexible programming paradigms without burdening programmers 
with platform-specific facilities or complex, error-prone dynamic protocols. We 
have deployed this server for our book’s widely accessed web site. 

Two major areas of future work involve type systems and interoperability. Re- 
search should explore how the essential additions to Scheme — dynamically link- 
able modules that are first-class values, threads, custodians, and parameters — 
can be integrated in typed functional languages such as ML and how the type 
system can be exploited to provide even more safety guarantees. While MrEd 
already permits programmers to interoperate with C programs through a foreign- 
function interface, we are studying the addition of and interoperation between 
multiple safe languages in our operating system, so programmers can use the 
language of their choice and reuse existing applications m- 

Acknowledgments. We thank Matthew Flatt and Darren Sanders for their 
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Abstract. In POPL’OO, Cousot and Cousot introduced and studied a 

-n* 

novel general temporal specification language, called M -calculus, in par- 
ticular featuring a natural and rich time-symmetric trace-based seman- 
tics. The classical state-based model checking of the ft-calculus is an 
abstract interpretation of its trace-based semantics, which, surprisingly, 
turns out to be incomplete, even for finite systems. Cousot and Cousot 
identified the temporal connectives causing such incompleteness. In this 
paper, we first characterize the least, i.e. least informative, refinements of 
the state-based model checking abstraction which are complete relatively 
to any incomplete temporal connective. On the basis of this analysis, we 
show that the least refinement of the state-based model checking seman- 
tics of (a slight and natural monotone restriction of) the A* -calculus which 
is complete w.r.t. the trace-based semantics does exist, and it is essen- 
tially the trace-based semantics itself. This result can be read as stating 
that any model checking algorithm for the M -calculus abstracting away 
from sets of traces will be necessarily incomplete. 



1 Introduction 

The classical semantics of standard temporal specification languages for model 
checking, like CTL, /i-calculus and variations thereof, are state-based and time- 
asymmetric [3,6,11,12]. State-based means that, given a transition system mod- 
elling some reactive system, the semantics of a temporal formula <j> is given by 
the set of states of the transition system satisfying (f>, possibly w.r.t. some en- 
vironment whenever <f> contains free variables. Time- asymmetry refers to the 
asymmetric nature of the classical notion of trace in transition systems, since 
traces are commonly indexed on natural numbers and therefore have a finite past 
and an infinite future. Recently, Cousot and^ Cousot [6] introduced a novel gen- 
eral temporal specification language, called M-calculus, inspired from Kozen’s [9] 
/x-calculus and featuring a time-symmetric trace-based semantics. In the M-cal- 
culus semantics, traces are indexed over integer numbers, i.e. both past and 
future are infinite, and a time reversal operator allows a uniform symmetric 
treatment of past and future. Traces record the present time, and hence the 
present state as well, by an integer number, and temporal formulae are therefore 
interpreted as sets of traces. The generality of the A< -calculus stems from mixing 
linear and branching time modalities, and this allows to recover most standard 
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specification languages like CTL, CTL* and Kozen’s /i-calculus as suitable frag- 
ments. 

The most relevant feature in Cousot and Cousot’s [6] work is in the appli- 
cation of the abstract interpretation methodology [4,5] to the M -calculus. In 
particular, it is shown how to derive standard state-based model checking by 
abstract interpretation from the trace-based semantics of the /^-calculus. This is 
performed exploiting a so-called universal checking abstraction map a \ f : given 
a model to check M (i.e., the set oftraces generated by some transition system), 
ot* M abstracts a trace-interpreted M -calculus temporal formula </> to the set of 
present states s of M such that any (here we are considering the universal case: 
dually, in the existential checking abstraction “any” becomes “some” ) execution 
of M departing from the state s satisfies (f). Thus, the abstract domain consists 
of sets of states, since a ^ abstracts sets of traces to sets of states. In particular, 
o^O) encodes a classical state-based interpretation like {s € States | M, s |= 0}, 
and therefore the state-based local model-checking problem of determining if a 
given state s in M satisfies <f> amounts to checking whether s £ a\ f ((p). This 
abstraction map from sets of traces to sets of states compositionally induces a 
state-based abstract semantics |-] state for the M -calculus, which, by construction 
through the abstract interpretation technique, is sound w.r.t. the trace-based se- 
mantics: for any formula (f>, cc J M (\4>\ trace ) A [c£] state . 

Completeness for the abstract state-based semantics in general does not hold, 
i.e. the containment above may be strict, even for finite systems (see [6, Coun- 
terexamjde (60)]). This means that trace-based and state-based model checking 
for the M -calculus, in general, are not equivalent: there exist some formula <f> 
and state s such that M, s | = troce </>, while M, s\/= state (J). The consequence of 
such incompleteness is that in order to deal with general temporal specifications 
of the M-calculus, model checking algorithms should handle sets of traces instead 
of sets of traces, and this is evidently infeasible. Moreover, Cousot and Cousot 
single out the sources of such incompleteness, that is, the temporal connectives 
of the M -calculus which are incomplete for the universal checking abstraction: 
these are the predecessor, shifting the present time one step in the past, the dis- 
junction, and the reversal, exchanging past and future w.r.t. the present time. 

Giacobazzi et al. [8] observed that completeness for an abstract interpreta- 
tion, i.e. abstract domains plus abstract operations, only depends on the un- 
derlying abstract domains. Hence, this opens up the key question of making an 
abstract interpretation complete by minimally extending the underlying abstract 
domain. Following the terminology in [8], we call complete shell of an abstract 
domain A the most abstract, i.e. containing the least amount of information, 
domain, when this exists, which extends A and is complete for some operation 
or (fixpoint) semantics. The relevance of such concept should be clear: the com- 
plete shell of an abstract domain A characterizes exactly the least amount of 
information which must be added to A in order to get completeness, when this 
can be done. It is shown in [8] that complete shells relative to sets of concrete 
operations, the so-called absolute complete shells, exist under weak and reason- 
able hypotheses, and some constructive methods to characterize them are given. 




